Discussion :

[riad_09]

bonjour j'ai une table qui contient comme champ: date, obj, col1, col2, col3.....

moi ce que je veut faire, c parcourir les colones pour chaque objet pour deux dates differentes puis extraire la diffirence si elle existe dans une nouvelle table

pour les colones j 'ai utiliser un cursor pour recupere le nom des colones depuis les tables systemes puis je faire une insruction sql pour comparer chaque ligne du cursor (nom de colone) dans les deux dates
code

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
CREATE PROCEDURE SP_Riad3
AS
 
-- variables locales de la procédure
DECLARE @NomTable VARCHAR(128),     -- nom de la table
        @SQL      VARCHAR(1000)     -- texte de la requête dynamique
 
-- pas de messages intempestifs
SET NOCOUNT ON
 
-- déclaration du curseur pour recuperer les noms des colonnes
DECLARE CursBase CURSOR 
FOR
   SELECT     COLONNES.name
FROM         syscolumns AS COLONNES INNER JOIN
                      sysobjects AS TABLES ON TABLES.id = COLONNES.id
WHERE     (TABLES.name = 'tableXXXX')
 
-- gestion de la table des résultats : nom de la table qui contiendra les differences
SET @NomTable = 'DATA'
 
-- vidage si existence de cette table, sinon création
IF EXISTS(SELECT * FROM   INFORMATION_SCHEMA.tables WHERE  TABLE_NAME = @NomTable)
   DELETE FROM DATA
ELSE
   CREATE TABLE DATA
   (
obj   VARCHAR(128),
    OLD   VARCHAR(128),
  NEW VARCHAR(128),
    diff VARCHAR(128))
 
-- ouverture du curseur
OPEN CursBase
 
-- lecture de la première ligne
FETCH CursBase INTO @NomTable
 
-- boucle ligne à ligne
WHILE @@FETCH_STATUS = 0
BEGIN
if @NomTable='Date' goto suite
 declare @str varchar(1500)
 
SET @str = 'INSERT INTO DATA SELECT     t1.obj, t1.' + @NomTable + '  AS old, t2.' + @NomTable +' AS NEW, ''' + @NomTable + ''' AS diff
FROM         tablexxx AS t1 INNER JOIN
                      tablexxx AS t2 ON t1.obj = t2.obj AND t1.'+@NomTable+' <> t2.'+@NomTable+' AND t1.Date < t2.Date'
 
suite:
print (@str)
exec (@str)
 
   FETCH CursBase INTO @NomTable
END
 
-- fermeture et désallocation d'espace mémoire du curseur
CLOSE CursBase
DEALLOCATE CursBase
 
-- envoi des données
SELECT * FROM DATA
 
-- pas de messages intempestifs
SET NOCOUNT OFF

exemple:
date obj col1 col2 col3
2008 XA oui 13 TRUE
2009 XA oui 15 FALSE


le resultat sera dans la table DATA comme suit :

obj OLD NEW Diif

XA 13 15 col2
XA TRUE FALSE col3


avec ce code j'ai un resultat dans 20 sec pour 5000 ligne mais le pb que ces tables grandissent du jour en jour
y'a t'il un moyen pour plus optimiser ce code

remarque: j'ai lier la table tablexxx avec elle meme (une fois t1 et une fois t2) je prend de t1 une date et t2 une autre date,
mais le pb que t1 et t2 contiennent tout les deux les deux dates donc c'est une redondance peut etre (temps de recherche sera plus long).
et puis sur quel colone on poura appliquer des index pour accelerer la recherche????
je pense que c'est un bon challenge les mec bonne chance
merci

[elsuket]

Bonjour,

L'utilisation de curseurs, pour quelque problème que ce soit, est à proscrire, comme je l'ai montré ici pour des raisons de performances, mais aussi parce que SQL est un langage qui est conçu pour traiter des ensembles de données dans leur globalité, et non pas traiter les éléments de ces ensembles un par un comme on peut le faire avec un curseur ou une boucle WHILE.
Donc quand vous programmez des bases de données, oubliez ce que vous avez appris des autres langages, où l'on traite les données de façon itérative.

le resultat sera dans la table DATA comme suit :

obj OLD NEW Diif

XA 13 15 col2
XA TRUE FALSE col3

Cela montre que votre modèle de données est incorrect : en aucun cas une colonne ne doit devenir une valeur !

avec ce code j'ai un resultat dans 20 sec pour 5000 ligne mais le pb que ces tables grandissent du jour en jour
y'a t'il un moyen pour plus optimiser ce code

5000 lignes c'est rien du tout pour beaucoup de moteurs de base de données, et 20s c'est beaucoup trop long pour traiter si peu de lignes.
Donc oui, on peut optimiser cela mais il faudrait que vous soyez plus précis sur la problématique et que vous soyez prêt à modifier votre modèle de données.

@++