est-il possible de faire un where avec une liste en paramètre

[amednagh]

Bonjour,
est-ce qu'il est possible de faire une requête (procédure stockée) avec comme paramètre une liste de données ?
je m'explique :
je veux envoyer une liste [a,b,c,d] a une procédure
et je veux faire une recherche avec ca, dire au système si mon ID existe dans [a,b,c,d]

select * from MaTable where ID exist dans [a,b,c,d]

je precise que je travail sur sql server 2005

merci par avance

[tumoo]

Salut

Oui tu peux avec le mot clé IN

Code sql :

SELECT * FROM MaTable WHERE ID IN (a,b,c,d)

[amednagh]

non ca passe pas

Envoyé par tumoo

Salut

Oui tu peux avec le mot clé IN

Code sql :

SELECT * FROM MaTable WHERE ID IN (a,b,c,d)

[tumoo]

Bah tu déclares 4 paramètres dans ta procédure,

et tu fais un

Code sql :

SELECT * FROM MaTable WHERE ID IN (@param1,@param2,@param3,@param4)

dans ta procédure

Pour l'appel,

Code sql :

exec ta_procédure @param1=a,@param2=b,@param3=c,@param4=d

Tu saisis le principe ?

[amednagh]

oui mais non lol
en fait y aura presque entre 1 et 2000 paramètres ca dépends des cases que l'utilisateur a coché dans un treeview (c#)

Envoyé par tumoo

Bah tu déclares 4 paramètres dans ta procédure,

et tu fais un

Code sql :

SELECT * FROM MaTable WHERE ID IN (@param1,@param2,@param3,@param4)

dans ta procédure

Pour l'appel,

Code sql :

exec ta_procédure @param1=a,@param2=b,@param3=c,@param4=d

Tu saisis le principe ?

[elsuket]

Bonjour,

C'est un problème récurrent et il existe trois façons de le résoudre :

- soit vous faites un INSERT dans une table à deux colonnes, réservée à cet effet : l'une est un identifiant de type uniqueidentifier, généré par la procédure stockée avec la fonction NEWSEQUENTIALID(), et vous stockez toutes les valeurs dans cette colonne.
Ensuite vous faites la jointure sur cette table en filtrant par l'identifiant

- soit vous utilisez des paramètres de type TABLE (TVP dans la littérature), qui sont plus stricts.
Mais comme ce sont des variables de type TABLE côté SQL Server, aucune statistique n'est maintenue sur une telle table (elle est stockée dans TempDB).
Donc l'estimation de cardinalité pour un grand nombre de valeurs est souvent faux à moins que vous terminiez la requête par OPTION (RECOMPILE).
Dans ce dernier cas, si la requête est exécutée très fréquemment, vous allez augmenter la consommation de CPU.

- Soit vous utilisez une fonction SQL de dépouillement de la chaîne, et vous faites une jointure sur la fonction table.
Vous aurez le même problème d'estimation de cardinalité que ci-dessus.

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
CREATE TABLE dbo.nombre
(
	nombre int NOT NULL CONSTRAINT PK_Nombres PRIMARY KEY CLUSTERED
)
 
SET NOCOUNT ON
 
DECLARE	 @max AS INT,
	@i AS INT
 
SELECT @max = 100000;
	, @i = 1;
 
WHILE @i<= @max
BEGIN
	INSERT dbo.nombre SELECT @i
	SET @i += 1
END
 
CREATE FUNCTION dbo.SplitStringToInt
	(
		@string AS VARCHAR(max)
	)
RETURNS TABLE
AS
	RETURN
		SELECT	CAST(SUBSTRING(@string, nombre, CHARINDEX(',', @string + ',', nombre) - nombre) AS int) AS element
		FROM	dbo.nombre
		WHERE	nombre<= LEN(@string) + 1
		AND	SUBSTRING(',' + @string, nombre, 1) = ','
GO

@++

[amednagh]

supeeeer merci Nicolas pour toutes ses explications

Envoyé par elsuket

Bonjour,

C'est un problème récurrent et il existe trois façons de le résoudre :

- soit vous faites un INSERT dans une table à deux colonnes, réservée à cet effet : l'une est un identifiant de type uniqueidentifier, généré par la procédure stockée avec la fonction NEWSEQUENTIALID(), et vous stockez toutes les valeurs dans cette colonne.
Ensuite vous faites la jointure sur cette table en filtrant par l'identifiant

- soit vous utilisez des paramètres de type TABLE (TVP dans la littérature), qui sont plus stricts.
Mais comme ce sont des variables de type TABLE côté SQL Server, aucune statistique n'est maintenue sur une telle table (elle est stockée dans TempDB).
Donc l'estimation de cardinalité pour un grand nombre de valeurs est souvent faux à moins que vous terminiez la requête par OPTION (RECOMPILE).
Dans ce dernier cas, si la requête est exécutée très fréquemment, vous allez augmenter la consommation de CPU.

- Soit vous utilisez une fonction SQL de dépouillement de la chaîne, et vous faites une jointure sur la fonction table.
Vous aurez le même problème d'estimation de cardinalité que ci-dessus.

Code :

@++

[iberserk]

A nico:

je precise que je travail sur sql server 2005

vous devez donc ignorer les TVP.