Discussion :

[Krison]

Dans le même thème: je me demande si recalculer toute une structure (càd rafraichir toutes les bornes) serait lourd ou non.

La solution d'arbres par représentation intervallaire me séduit mais dans mon cas, la structure existe déjà (StructId, ParentId).
Je n ai pas de grands arbres (+- 5 niveaux).

Je me mets a essayer rapidement d'écrire une procédure qui me fixerait les bornes. Si ce n'est pas trop lourd, je compte me passer de toute une gestion "immédiate" (update/insert/delete) pour ne garder qu'une "grosse" procédure de rafraichissement.

...edit:

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
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
 
BEGIN TRAN
--Declare
DECLARE @Counter                INTEGER
DECLARE @LoopMax                INTEGER
DECLARE @ActualParentId    BIGINT
DECLARE @ActualChildId    BIGINT
 
DECLARE @ActualTreeL        INTEGER
DECLARE @ActualTreeR        INTEGER
DECLARE @ActualLevel        INTEGER
 
--Init
SELECT @Counter = COUNT(*) FROM Est_Structure WHERE Est_HeaderId = 1
SET @ActualParentId = NULL
SET @ActualChildId = NULL
SET @ActualLevel = 0
SET @LoopMax = @Counter
 
--Reset All
UPDATE Est_Structure set TreeL=NULL, TreeR=NULL WHERE Est_HeaderId = 1
--Set root:
UPDATE Est_Structure SET TreeL = 1, Level = 0, TreeR = @Counter*2
   WHERE Est_HeaderId = 1 AND ParentId IS NULL
 
SET @Counter = 0
WHILE EXISTS (SELECT NULL FROM Est_Structure WHERE Est_HeaderId = 1 AND TreeL IS NULL)
    AND @Counter < @LoopMax
BEGIN
    -- Loop - Begin
    SET @Counter = @Counter + 1
    SELECT TOP 1 @ActualChildId = Child.Est_StructureId, @ActualParentId = Child.ParentId
            , @ActualTreeL = Parent.TreeL
            , @ActualLevel = Parent.[Level]
        FROM Est_Structure Child INNER JOIN Est_Structure Parent ON Parent.Est_StructureId = Child.ParentId
        WHERE Child.Est_HeaderId = 1
            AND Child.TreeL IS NULL
            AND Child.ParentId IS NOT NULL
            AND ( @ActualParentId IS NULL OR (@ActualParentId IS NOT NULL AND @ActualParentId = Child.ParentId))
        ORDER BY Child.[Level], Child.[Type] DESC
 
    --Get next value of TreeL...
    SELECT @ActualTreeL = ISNULL(MAX(TreeL),1) FROM Est_Structure WHERE Est_HeaderId = 1 AND TreeL IS NOT NULL
    SELECT @ActualTreeR = ISNULL(MAX(TreeR),0) FROM Est_Structure WHERE Est_HeaderId = 1 AND TreeR IS NOT NULL AND ParentId IS NOT NULL --AND TreeR < @LoopMax
    SELECT @Error = @@ERROR, @Rowcount = @@ROWCOUNT
    IF @ActualTreeR IS NOT NULL AND @ActualTreeR > @ActualTreeL
    SET @ActualTreeL = @ActualTreeR
 
    IF NOT EXISTS (SELECT NULL FROM Est_Structure WHERE Est_HeaderId = 1 AND ParentId = @ActualChildId)
    BEGIN
        --Feuilles... TreeR = TreeL + 1
        UPDATE Est_Structure SET TreeL = @ActualTreeL+1, TreeR = @ActualTreeL+2
            , [Level] = @ActualLevel+1
            WHERE Est_StructureId = @ActualChildId
        SET @ActualTreeL = @ActualTreeL + 2
    END
    ELSE
    BEGIN
        UPDATE Est_Structure SET TreeL = @ActualTreeL+1
            , [Level] = @ActualLevel+1
            WHERE Est_StructureId = @ActualChildId
        SET @ActualTreeL = @ActualTreeL + 1
 
        IF EXISTS (SELECT NULL FROM Est_Structure WHERE ParentId = @ActualChildId AND TreeL IS NULL)
        BEGIN
            PRINT 'Use ChildId as ActualParentId...'
            UPDATE Est_Structure SET TreeR = @ActualTreeL+1 WHERE TreeR IS NULL AND Est_StructureId = @ActualParentId AND ParentId IS NOT NULL
            IF @@ROWCOUNT > 0 SET @ActualTreeL = @ActualTreeL + 1 
            SET @ActualParentId = @ActualChildId
        END            
    END
 
    WHILE @ActualParentId IS NOT NULL
        AND NOT EXISTS (SELECT NULL FROM Est_Structure WHERE Est_HeaderId = 1 AND TreeL IS NULL AND ParentId = @ActualParentId)
    BEGIN
        UPDATE Est_Structure SET TreeR = @ActualTreeL+1 WHERE TreeR IS NULL AND Est_StructureId = @ActualParentId
        IF @@Rowcount > 0 SET @ActualTreeL = @ActualTreeL + 1 
        SELECT @ActualParentId = ParentId FROM Est_Structure WHERE Est_StructureId = @ActualParentId
    END
    -- Loop - End
END
 
--Results:
SELECT Est_StructureId, ParentId, Level, Rang, TreeL, TreeR, Type, BDE_NR, Bezug, Pos, Artikel
    FROM Est_Structure
    WHERE Est_HeaderId = 1
--        AND TreeL IS NOT NULL
--     AND (BDE_NR = 464915 OR BEZUG = 464915)
    ORDER By TreeL, Rang, BDE_NR, Pos, [Level]
 
ROLLBACK

63ms pour un arbre sur 4 niveaux composé de 92 rows... ok pour moi
(...Est_HeaderId est l'identifiant de mon arbre...)

[SQLpro]

Avez vous fait des tests en concurrence ? Par ce que des test en mono utilisateur dans une base de données c'est inutile !

A +

[Krison]

Non, je n ai pas fait des tests en concurrence.
Je voulais tout d abord vérifier que ce genre de solution etait concevable.

Dans mon cas, la concurrence n a pas trop d interet: le concept donne un proprietaire a l arbre. Un autre utilisateur pourrait cependant (dans de rare cas) le parcourir en meme temps, mais pas le modifié.

Des que j ai vu que ca avait l air de tenir la route, j ai ecrit mon code plus proprement (gestion d erreurs, WITH (NOLOCK),...)

Je concois bien que ce genre de solution ne peut pas toujours convenir! Je supposais que c etait clair... mais c est vrai qu il vaut mieux prevenir...

Merci

Edit:
Au niveau performance, j ai réessayé avec un plus grand arbre (composé de 1185 rows/ level 7)... il me faut en moyenne +-1200ms... bof bof au niveau performance. Dans mon cas: l arbre ne devrait jamais etre aussi grand (mais bon... la theorie et la pratique...). Ca reste acceptable pour mon projet... ca ne le sera pas dans d autres cas!
Toute optimisation sera la bienvenue

[SQLpro]

En matière de BD les temps de réponse sont rarement linéaires. Ils sont généralement exponentiel sans indexation et logarithmique avec les bons index. Et surtout, pour pouvoir réellement apprécier un test il faut un volume minimale de données (généralement supérieur à la RAM du serveur) et plusieurs accès concurrent. Autrement dit avec 100 ou 1000 lignes c'est du pipi de chat !

L'utilisation de NOLOCK n'y changera rien (c'est une aberration et une preuve que le sujet n'est pas maitrisé en général) car dans les mises à jour, il y a toujours verrouillage des tables.

Enfin, la mise à jour au fil de l'eau (donc à chaque INSERT/UPDATE/DELETE) dilue les temps de réponse qui deviennent quasi invisible, alors que le batch, même s'il est globalement moins couteux, verrouillera plus longtemps ce qui donnera vu de l'utilisateur des temps de réponse erratique en sus d'exposer des données fausses.

Bref, votre méthode est totalement inadaptée et montre qu'en matière de développement vous en êtes resté à l'itératif et non à l'ensembliste ni au transactionnel !

A +

[Krison]

Un paramètre a ne pas néglier: le temps consacré à ce projet: très limité (en heures...pas en jours)
et son utilisation : 4 personnes... quelques fois sur la semaine...(+-5x => appel de +-5x de cette procédure)
C est juste une question de priorité: le temps que je n utilise pas ici, je l utilise a gagner du temps là ou c est vraiment nécessaire.

100 ou 1000 lignes c'est du pipi de chat !

c est clair => d ou l interet de ne pas perdre trop de temps à essayer de gagner du temps.

[SQLpro]

Vous pouvez parfaitement utiliser les procédures que j'ai mis au point : soit en ajoutant les colonnes à la table, soit en ajoutant une table liée en 1:1 à la table source et en utilisant des déclencheurs pour ce faire.

Voici les code des PS que j'ai écrit :
http://blog.developpez.com/sqlpro/p8...allaire-proce/
http://blog.developpez.com/sqlpro/p7...dure-de-depla/
http://blog.developpez.com/sqlpro/p7...dure-de-derec/

A +

[Krison]

tip top pour faire ca proprement. J espere trouvé du temps pour le faire. Ensuite ce sera egalement disponible pour d autres futurs projets