Déclaration de variable avec valeurs multiples regroupées

Bonjour

Je souhaite déclarer des variables regroupées:

Soit le champ REF qui prend ses valeurs sur 4 caractères selon le modèle suivant: 0001, 0002, 0003, 0004 etc...

Je veux pouvoir le scinder (par exemple) en

REF_1 qui comprend les valeurs [0001,0009,0025,0985]
REF_2 qui comprend les valeurs [0002,0003,0222,0246,0333,0456,0999]
etc etc...avec les variables REF_X comprenant un nombre variable de valeurs REF sur 4 caractères

NB: Ces REF sont bien sûr listées dans une table TABLE_REF

DECLARE @REF_1 (ici je ne sais pas quoi mettre comme format: VARCHAR(xxx)?
SET @REF_1= [0001,0009,0025,0985] en utilisant la syntaxe correcte, les virgules, les parenthèses ne fonctionnent pas

pour avoir une requête du type:

Code:

---

1 2 3 4

SELECT * FROM MATABLE WHERE MATABLE.REF =@REF_1 etc...

---

Merci de votre réponse

Cordialement

Bonjour

Pouvez vous nous en dire plus sur le contexte, on comprendra surement mieux le but de tout ca. Sur le principe, je pense qu'il vous faut une variable table...

Mais vous pouvez peut être faire directement une jointure sur la table des références, ce qui serait nettement mieux ?

Comment est générée et d'ou provient la liste des références pour la requête ?

Citation:

---

Mais vous pouvez peut être faire directement une jointure sur la table des références, ce qui serait nettement mieux ?

---

En effet cela me semble surtout être une usine à gaz bien dégueul...

Faire une jointure sur ma table des références ne me sert à rien (je sais faire et ce n'est pas ce que je veux car sinon, outre le fait que je l'aurais déjà fait, mon problème est de ne pas perdre mon temps à rentrer des conditions différentes à chaque requête; d'où le principe de la variable ;=)))

=>Ce que je veux, c'est regrouper un certain nombre de références de cette table (ou d'ailleurs n'importe quelle valeur provenat d'une autre table ou non) et les déclarer en variable. D'autant plus que je veux déclarer PLUSIEURS groupes de variables

Par analogie, imaginons que je ne veuille déclarer qu'une seule valeur:

Code:

---

1 2 3 4 5

DECLARE @REF CHAR(4) SET @REF='0001'   SELECT * FROM MATABLE WHERE MATABLE.MONCHAMP=@REF

---

Imaginons maintenant que je veuille PLUSIEURS valeurs (un groupe de plusieurs valeurs) déclarées par variable

Il faudrait une syntaxe qui fonctionne et me permette par analogie:

DECLARE @REF CHAR(4)
SET @REF=('0001','0003','0006') et en l'occurrence peu importe que ces données soient issues d'ailleurs ou non d'une des tables de ma base

Je crois qu'il y a la possibilité de déclarer des variables '@Tables', chaque table correspond à un certain nombre de valeurs; cela répondrait à mon problème, mais je n'arrive pas à comprendre correctement la syntaxe sur ce que je trouve via Mr google

Il y aurait quelque chose qui ressemblerait à

Code:

---

1 2 3

DECLARE @TABLE_REF1 ... DECLARE @TABLE_REF_x

---

puis il faut la syntaxe pour remplir la table et faire le SET


Merci

Créez un userType dans votre base de données de type TABLE avec la structure que vous voulez...

Ensuite vous pouvez définir cette variable comme variable d'entrée de votre procédure stockée par exemple et l'utiliser comme une table normale...

Ces tables s'appelles plus communemment Table Valued Parameter (TVP) et peut être manipulé également en C# (sauf LINQ TO SQL je crois).

Il est toutefois déconseillé de les utiliser pour de la volumétrie (>1000)

Citation:

---

Envoyé par Dr_No

et en l'occurrence peu importe que ces données soient issues d'ailleurs ou non d'une des tables de ma base

---

Bah si justement, cela à de l'importance. Cela permettrait selon les cas des requêtes plus simples et surtout plus performantes.

Car votre problème a de nombreuses solutions, de la plus performante, à la plus crade simple :aie: :

Et savoir comment est générée la liste est important, ainsi que son format !

Merci Iberserk mais si je comprends le principe, je ne sais pas comment faire en pratique car je n'ai pas assez de bagage.

Je ne connais pas le C# non plus (enfin je veux dire que je n'en connais pas la syntaxe)


J'imagine quelque chose comme:

Code:

---

1 2 3 4 5

DECLARE @MATABLEVAR ( MONCHAMP_1 CHAR(4), MONCHAMP_2 CHAR(30) )

---

Mais comment rentrer les différentes valeurs des colonnes de MATABLE?

Si je prends des valeurs issues d'une table de ma base (ce qui ne règle pas le problème pour des valeurs autres que je souhaiterais renseigner)

J'essaye cela:

Code:

---

1 2 3 4

INSERT INTO @MATABLEVAR (MONCHAMP_1,MONCHAMP_2) SELECT MONCHAMP_x, MONCHAMP_y FROM MONAUTRETABLE GROUP BY MONCHAMP_1,MONCHAMP_2

---

Je ne sais pas s'il faut faire comme ça, mais dans l'affirmative, comment faire après?

Code:

---

1 2 3

SELECT * FROM ENCOREAUTRETABLE WHERE ENCOREAUTRETABLE.MONCHAMP_n IN @MATABLEVAR.MONCHAMP_1

---

Cela ne marche pas

Cordialement

Citation:

---

Je ne connais pas le C# non plus (enfin je veux dire que je n'en connais pas la syntaxe)

---

Pardon je vous parlais de C# car je pensais que vous posiez la question dans le cadre d'un developpement applicatif, c'était un exemple

Citation:

---

DECLARE @MATABLEVAR
(
MONCHAMP_1 CHAR( 4),
MONCHAMP_2 CHAR(30)
)

Mais comment rentrer les différentes valeurs des colonnes de MATABLE?

Si je prends des valeurs issues d'une table de ma base (ce qui ne règle pas le problème pour des valeurs autres que je souhaiterais renseigner)

J'essaye cela:

INSERT INTO @MATABLEVAR (MONCHAMP_1,MONCHAMP_2)
SELECT MONCHAMP_x, MONCHAMP_y
FROM MONAUTRETABLE
GROUP BY MONCHAMP_1,MONCHAMP_2

---

Oulà vous êtes un peu perdu dans le concept!

Vous allez créer un type table

Code:

---

1 2 3 4

DECLARE @MATABLEVAR ( MONCHAMP_1 CHAR(4) )

---

l'alimenter (c'est là que je rejoins aieuuuuuuuu(je paume toujours un 'u' :mrgreen: pardon ) et m'interroge sur la manière dont vous allez alimenter cette table...):

Code:

---

1 2	INSERT INTO @MATABLEVAR (MONCHAMP_1) VALUES('REF22'),(REF23)

---

Puis vos traitements:

Code:

---

1 2 3 4

SELECT * FROM ENCOREAUTRETABLE A INNER JOIN @MATABLEVAR B ON B.MONCHAMP_1=A.MONCHAMP

---

Au passage on ne parle pas de champ en base de données mais de colonnes...

J'ai appelé ma colonne MONCHAMP, c'est osé
;)

Pour le reste, merci j'essaye dès l'aube demain et reviens (je l'espère) clore le thread

Merci

ce la n'a pas l'air de marcher.

Voici avec une requête simple sur une Table de ma Base ce que cela donne

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

DECLARE TABLE @POLE_BACH ( IUUF_BACH CHAR(4), )   INSERT INTO @POLE_BACH (IUUF_BACH) VALUES ('0007'),('0008'),('0322')     SELECT * FROM EPISHOS INNER JOIN @POLE_BACH ON EPISHOS.IUUF=@POLE_BACH.IUUF_BACH WHERE LEFT(EPISHOS.DATSRTSJR,4)='2011'

---

Voici les Messages d'Erreur:

Serveur*: Msg 156, Niveau 15, État 1, Ligne 1
Syntaxe incorrecte vers le mot clé 'TABLE'.

Serveur*: Msg 1087, Niveau 15, État 1, Ligne 6
La variable de table "@POLE_BACH" doit être déclarée.

Serveur*: Msg 1087, Niveau 15, État 1, Ligne 12
La variable de table "@POLE_BACH" doit être déclarée.

Bonjour,

Changez :

Code:

---

1 2 3 4

DECLARE TABLE @POLE_BACH ( IUUF_BACH CHAR(4), )

---

Par :

Code:

---

1 2 3 4

DECLARE @POLE_BACH TABLE ( IUUF_BACH CHAR(4), )

---

@++ ;)

C'est mieux, cela enlève une partie des messages mais:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

DECLARE @POLE_BACH TABLE ( IUUF_BACH CHAR(4) ) INSERT INTO @POLE_BACH (IUUF_BACH) VALUES ('0007'),('0008'),('0322')   SELECT * FROM EPISHOS INNER JOIN @POLE_BACH ON EPISHOS.IUUF=@POLE_BACH.IUUF_BACH WHERE LEFT(EPISHOS.DATSRTSJR,4)='2011'

---

Message d'ERREUR:

Serveur*: Msg 137, Niveau 16, État 1, Ligne 12
La variable scalaire "@POLE_BACH" doit être déclarée.

On s'approche!!

Utilisez un alias pour votre table variable dans la requete :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

DECLARE @POLE_BACH TABLE ( IUUF_BACH CHAR(4) ) INSERT INTO @POLE_BACH (IUUF_BACH) VALUES ('0007'),('0008'),('0322')   SELECT * FROM EPISHOS INNER JOIN @POLE_BACH P ON EPISHOS.IUUF=P.IUUF_BACH WHERE LEFT(EPISHOS.DATSRTSJR,4)='2011'

---

Cela dit, au risque de me répéter, je ne vois pas l'intérêt de cette table variable ici :

Code:

---

1 2 3 4 5

SELECT * FROM EPISHOS WHERE IUUF IN ('0007','0008','0322') AND LEFT(DATSRTSJR,4)='2011'

---

Citation:

---

INSERT INTO @POLE_BACH (IUUF_BACH)
VALUES ('0007'),('0008'),('0322')

---

Citation:

---

Cela dit, au risque de me répéter, je ne vois pas l'intérêt de cette table variable ici :

---

Je pense qu'à terme il veut rendre çà un peu dynamique ou le passer en paramètre de procedure etc. (enfin j'espère :mouarf:)

Bon cela fonctionne

Sur le fond, bien évidemment une procédure va s'imposer.

Mais ce sont les informaticiens qui ont la main :aie: (du reste je ne sais pas -encore- faire une procédure stockée), et en attendant, sur un système usine à gaz sur lesquelles je dois faire des multiples regroupements pour faire des requêtes sensiblement plus complexes qu'un SELECT * sur une table unique; si je peux m'éviter de me tartiner à taper de multiples fois des variables différentes, j'ai déjà gagné du temps

EN tous cas merci à tous

Citation:

---

Envoyé par Dr_No

du reste je ne sais pas -encore- faire une procédure stockée

---

C'est peut être la raison pour laquelle ma question vous paraissait futile :

Citation:

---

Envoyé par aieeeuuuuu

Comment est générée et d'ou provient la liste des références pour la requête ?

---

Mais je vous conseille de reconsidérer la question : comment allez vous passer cette liste de valeurs à votre procédure stockée ?
Car même si cette question parait bien secondaire, cela va en fait conditionner les façons de faire la requête ensuite !

Merci

Je vais d'ores et déjà me pencher sur la question, dans un premier temps apprendre à écrire des procédures stockées et voir quelles sont les obligations à remplir.

Merci en tous cas de vos réponses, et de vos conseils

Utiliser une variable de type table est de toute façon une erreur :

- soit de méconnaissance de T-SQL,
- soit de conception de la base de données.

D'autre part vous noterez que lorsque vous utilisez une variable de type table, SQL Server estimera toujours qu'elle contient une et une seule ligne, et vous ne pouvez rien faire pour changer cela.

En conséquence, cela peut conduire l'optimiseur de requêtes à sur ou sous-estimer les cardinalités, donc utiliser des index qui ne conviennent pas à la requête en terme de performance.

La raison sous-jacente est que SQL Server ne maintient aucune statistique sur une telle table (car oui, une variable de type table, comme toute table, est persistée physiquement dans la base de données TempDB, base de données système utilisé pour bien d'autre choses que vos chères données !)

Le mieux reste donc d'utiliser une véritable table utilisateur, quitte pour cela à passer une liste de valeurs (mais là encore cela révèle une mauvaise conception) dans une chaîne de caractères, et à la dépouiller pour en extraire les valeurs atomiques, puis les insérer dans la table.

@++ ;)

Elkuset, cette réponse m'intéresse mais je n'en saisis pas forcément toute la portée.

En effet

1.La base est particulièrement mal conçue
2.Ma méconnaissance de T-SQL est grande

Mais c'est justement en raison du point 1 que ne pouvant pas extraire correctement certaines données, mais aussi en raison du point 2, que j'essaye d'arriver à mes fins. et si les moyens que j'essaye de mettre en oeuvre pour cela sont inappropriés informatiquement parlant, faute d'expertise suffisante, je suis sur la voie de la connaissance :8O

Et je pars de loin; du début dirais-je...

De ce point de vue 'it's a long way to the top....'

Citation:

---

La raison sous-jacente est que SQL Server ne maintient aucune statistique sur une telle table (car oui, une variable de type table, comme toute table, est persistée physiquement dans la base de données TempDB, base de données système utilisé pour bien d'autre choses que vos chères données !)

---

En pratique, et c'est à la marge mais pour ma culture, sous quelle forme, dans quelle table, combien de temps cette table est-elle persistée dans TempDB?

Citation:

---

Le mieux reste donc d'utiliser une véritable table utilisateur, quitte pour cela à passer une liste de valeurs (mais là encore cela révèle une mauvaise conception) dans une chaîne de caractères, et à la dépouiller pour en extraire les valeurs atomiques, puis les insérer dans la table.

---

Je ne peux qu'être d'accord.

Bye:ccool:

Citation:

---

En pratique, et c'est à la marge mais pour ma culture, sous quelle forme, dans quelle table, combien de temps cette table est-elle persistée dans TempDB?

---

- Sous quelle forme : une vraie table, comme je le montre dans l'article que je vous ai mis en lié sur le mot persistée de mon précédent post ;)

- Dans quelle table : son nom est calculé à l'exécution, c'est une suite de chiffres et de lettres

- Combien de temps : elle est conservée pour la durée de la session.
Dès que la session est fermée, la table est supprimée.

@++ ;)

Je n'avais pas remarqué le lien sur persistée!

Merci pour l'article!

Gloups, le WE arrive et force est de constater que d'insoupçonnées donnée factuelles existaient en dehors de tout champ de ma conscience...!!!!:mouarf:

Le WE n'en sera que meilleur, SURF (pour de vrai sur de vrais vagues) au programme

Merci encore pour cette aide précieuse.