Discussion :

[digofwall]

Bonjour

dans un code c# j'ai un Array 1 dimension composé d'Int , qui contient a chaque fois un ID , pour chaque indice du tableau je veut connaitre un " resultat " grâce à l'ID "

alors pour le moment je fais une boucle qui va a chaque fois appeler la procédure stockée

pour chaque ID dans array
{
appel procédure
getesultat avec parameters ID indice i
}

je trouve ça un peu bourrin , donc j'aimerais savoir si c'est possible d'envoyer directement le tableau , et ensuite en T-SQL stored proc , renvoie tout les ID dans l'odre

Merci

[hmira]

Depuis SQL Server 2008, il existe la notion «Paramètres table».

Les paramètres table sont déclarés en utilisant des types table préalablement définis par l'utilisateur.

Tu pourras ainsi utiliser des paramètres table pour envoyer plusieurs lignes de données à une procédure stockée ou une fonction, et ce, sans créer ni table temporaire (du moins explicite !) ni de nombreux paramètres.

Ci-dessous un lien qui explique cette nouvelle fonctionnalité (paramètre table) de SQL Server 2008 :
http://msdn.microsoft.com/fr-fr/library/bb510489.aspx


PS : Sa mise en œuvre en C# est par ailleurs très simple.

A+

[elsuket]

Bonjour,

Je ne suis pas vraiment d'accord avec cette approche.
En effet, pour une variable de type table, SQL Server ne maintient aucune statistique de colonne, et il estimera toujours qu'il n'y a qu'une seule ligne dans la variable de type table, ce qui est bien souvent faux.
Cela le conduit parfois à sous-estimer les cardinalités, et donc à produire des plans de requête sous-optimaux.

Il vaudrait mieux réutiliser la requête qui produit les ID pour écrire une procédure stockée qui calcule un résultat à partir ce ceux-ci.

S'il s'agit d'une sous-ensemble d'IDs de l'ensemble "source" (par exemple on produit une liste d’éléments et l'utilisateur a le choix d'en sélectionner quelques uns pour voir leurs caractéristiques), on peut stocker les ID de ce nouveau sous-ensemble dans une table utilisateur, avec un identifiant unique généré à l'exécution pour éviter les collisions pour deux exécutions concurrentes.

@++

[SQLpro]

S'il s'agit d'une sous-ensemble d'IDs de l'ensemble "source" (par exemple on produit une liste d’éléments et l'utilisateur a le choix d'en sélectionner quelques uns pour voir leurs caractéristiques), on peut stocker les ID de ce nouveau sous-ensemble dans une table utilisateur, avec un identifiant unique généré à l'exécution pour éviter les collisions pour deux exécutions concurrentes.
@++

Non seulement j'approuve, et j'ai mise en prod de nombreuses fois ce procédé et je vous conseille pour l'identifiant transactionnel d'utiliser un GUID et de prévoir un nettoyage des lignes après utilisation (et une table parfaitement indexée)

A +

[elsuket]

C'est exactement ce que je fais pour l'application sur laquelle je travaille.
La table qui gère cela reçoit énormément d'INSERT (donc autant de DELETE).
Les clients ne s'en sont jamais plaint en plus d'un an ...

@++

[hmira]

Même si je ne suis pas à l'origine du topic, tu tiens à vous remercier pour ce complément d'info.

Donc si je comprend bien, les ingénieurs de chez MicroSoft auraient du s'abstenir de proposer à partir de SQL Server 2008 cette nouvelle fonctionnalité «Table-Valued Parameters »

Ou bien existe t-il des cas d'utilisation simple où on peut considérer que les Table-Valued Parameters peuvent être utilisées sans porter préjudices aux performances. Je pense notamment à une procédure qui dans la pratique ne recoit que quelques dizaines (10, 20 ou 100) de paramètre, c.à.d une Table-Valued Parameters de 100 lignes maximum ?

A+