Opération sur lignes d'une table

Bonjour,

Je débute en T-SQL, et j'aimerai savoir s'il est possible de faire des opérations sur les lignes (enregistrements) d'une table a l’intérieur d'une procédure stocké.

Un peu comme on le fait avec un datareader et une boucle while MonDatareader.read.

Merci d'avance
Gilles

oui. Il existe plusieurs techniques :

1. les curseurs (à éviter s'il s'agit d'une opération à chaud en heure de production )

2.
a) Création de table temporaire (#Tmptable)
b) Remplissage de la table temporaire
c) WHILE EXISTS ( SELECT … FROM #Tmptable)
BEGIN
SET @ligneAtraiter = SELECT TOP 1 … FROM #Tmptable
instrustion à exécuter avec @ligneAtraiter
DROP de la ligne traitée dans la table #Tmptable
END
d) DROP de la table #Tmptable à la fin

Merci beaucoup de ta réponse rapide.
Super idée de mettre ça dans une table temporaire puis de l'effeuiller.

Bonjour,

En ce qui concerne les curseurs, ils sont tout simplement à éviter, comme je l'ai montré ici.

SQL est un langage déclaratif et ensembliste, ce qui signifie :

- que l'on spécifie seulement le résultat que l'on veut obtenir, et pas la façon de l'obtenir. Donc en dehors d'une procédure stockée de maintenance de base de données (c'est-à-dire pas des données elles-mêmes), les curseurs et WHILE sont contre-performants
- que les moteurs de bases de données relationnelles SQL sont optimisés pour traiter les données dans leur ensemble, et pas tuple par tuple, par exemple. Cherchez R-BAR ;)

Citation:

---

Un peu comme on le fait avec un datareader et une boucle while MonDatareader.read.

---

La façon dont on gère les données dans une application n'a rien à voir avec celle d'une base de données relationnelle SQL.

Enfin copier des données dans TempDB n'est pas une bonne démarche, puisque :

- d'une part il s'agit de copier des données que l'on a déjà, ce qui va à l'encontre du principe de non-redondance des données
- d'autre part, lorsqu'on exécute des procédures stockées qui font recours aux tables temporaires ou aux variables de type TABLE en parallèle, se pose tout ou tard un problème de contention au niveau des pages d'allocation dans les fichiers.

Bref, si vous voulez faire quelque chose de peu-performant et peu robuste, vous ne pouvez pas mieux vous y prendre :)

@++ ;)

Bonjour

Merci pour ta reponse, je suis bien conscients que ce n'est pas la meilleur facon de faire, mais je n'ai pas vraiment le choix.

La table dont j'ai besoin doit etre entierement construite sur une procedure stocké et pas par sur un ordi, car elle sera interrogée et modifié par un téléphone sous android. Tu comprend donc que ce n'est pas android qui va me mettre en forme la table puis la renvoyer sur le serveur.

De plus il faut aussi prendre en considération le fait que nous somme 3 au pire 4 à etre connecté sur la base (et rarement en meme temps), rajoute a ca que la plus grande table contient 2000 champs (ce qui n'est pas énorme) je ne pense pas écrouler le serveur AZURE.

derniere chose, je compte procéder comme ceci:
je crée une table temporaire
j'y met le resultat d'une requete qui devrait contenir moins de 100 enregistrements.
je passe en revue chaque enregistrement de la table temporaire
la j'ai un traitement a faire qui doit en fonction de certaine condition me remplir la table final.

Un exemple simple pour que tu comprennes mieux:
- 1 table client
- 1table facture
- 1table prelevement

je fais une requete select du genre

Code:

---

select Nom, Num Facture, date limite Payement, prelevement from client where facture.payé =0 inner join Factures

---

j'obtiens donc un resultat de la sorte

Code:

---

1 2 3 4 5

Nom Num Facture date limite Payement prelevement toto 123456 15/10/2012 mensuel toto 254525 10/11/2012 mensuel titi 444454 12/12/2012 Cheque titi 888888 20/12/2012 Cheque

---

Maintenant pour chaque factures de toto je dois:
- savoir si on a dépassé la date limite - 5 jours ouvré s'il est au prélèvement
- regroupé les deux enregistrements toto et titi

Dans la table finale je veux obtenir

Code:

---

1 2 3 4

Nom date limite Payement Fact1 Fact2 Prelevement est a jour date limite d'enregistrement toto 15/10/2012 123456 254525 Mensuel non 08/10/2012 titi 12/12/2012 444454 NULL Cheque oui NULL

---

Voila grosso modo l'esprit de ce que je veux faire, et je te passe la table relance ou il faut aussi gerer les dates de relance dans le meme esprit.

Je suis d'accord pour le principe de non redondance des données, seulement dans mon cas les données ne le sont pas toutes (ex je n'ai pris que la date la proche proche).
De plus le moteur SQL même s'il n'est pas fait pour cela, sera toujours plus rapide qu'un envoie de la totalité des données en 3g puis un traitement par Android.

Comme je l'ai dit au départ, je suis débutant sous SQL server, je suis donc preneur de toutes les remarques.
Merci d'avoir eu le courage de lire jusqu'au bout ;)
Gilles