Précédent   Forum des professionnels en informatique > Bases de données > Décisions SGBD
Décisions SGBD Forum de décisions sur le choix en bases de données. Le Comparatif
Partagez cette discussion sur d'autres réseaux sociaux : Viadeo Twitter Google Facebook Digg Delicious MySpace Yahoo
Réponse Proposer ce sujet en actualité
 
Outils de la discussion
Publicité
'
Vieux 04/11/2004, 11h18   #1
Invité de passage
 
Inscription : avril 2003
Messages : 9
Détails du profil
Informations forums :
Inscription : avril 2003
Messages : 9
Points : 1
Points : 1
Par défaut Représentation intervallaire des listes arborescentes

Bonjour à tout le monde !

J'ai lu l'excellent article de SQLPro concernant la représentation intervallaire des listes arborescentes http://sqlpro.developpez.com/cours/arborescence/.
Je me suis d'abord intéressé à la problématique de l'accès concurrent dans le cas de l'insertion (je ne suis pas allé plus loin) et il me semble avoir trouvé une faille dans la manière de faire et je soumets à votre sagacité ma réflexion (qui, je l'espère, n'est pas foireuse car je connais plus Oracle que SQLServer !).
Dans le code la procédure SP_INS_NOMENCLATURE, il y a dès le début le commencement d'un transaction :
Code :
1
2
3
-- démarrage transaction 
 SET TRANSACTION ISOLATION LEVEL SERIALIZABLE 
 BEGIN TRANSACTION INSERT_NOMENCLATURE
puis il y a la récupération de la valeur du père :
Code :
1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
-- Le parent existe toujours ?
 SELECT @OK = count(*) FROM T_NOMENCLATURE_NMC WHERE NMC_ID = @id_parent
 IF @OK = 0 OR @OK IS NULL
 BEGIN
    RAISERROR ('Insertion impossible, le parent n''existe plus !', 16, 1)
    GOTO LBL_ERROR
    RETURN
 END
 
-- On a un parent : on récupère ses éléments
 SELECT @bgp = NMC_BG, @bdp = NMC_BD, @nivp = NMC_NIVEAU 
        FROM T_NOMENCLATURE_NMC 
        WHERE NMC_ID = @id_parent
puis enfin, il y a la mise à jour des bornes dans les différents cas :
Code :
1
2
3
4
5
6
7
8
-- insertion d'un père
 IF @mode = 'P'
 BEGIN
    -- Décalage de l'ensemble colatéral droit
    UPDATE T_NOMENCLATURE_NMC
           SET NMC_BD = NMC_BD + 2
           WHERE NMC_BD > @bdp
...
Sur le principe, j'ai 2 remarques à faire :
1°) la première est que faire SELECT @OK=count(*)... pour savoir si le parent existe toujours n'est pas suffisant car l'enregistrement peut être modifié (bornes modifiées par exemple) ou supprimé entre temps quand on fait le SELECT @bgp=... suivant. Il faudrait faire un SELECT WITH HOLDLOCK (ou un SELECT FOR UPDATE en Oracle)
2°) en conséquence du 1°) les UPDATE pour modifier les bornes peuvent être faux.

Vos avis ?
PMAR est déconnecté   Envoyer un message privé Réponse avec citation 00
Vieux 05/11/2004, 09h35   #2
Rédacteur/Modérateur

 
Avatar de SQLpro
 
Homme Frédéric BROUARD
Expert SGBDR & SQL
Inscription : mai 2002
Messages : 10 959
Détails du profil
Informations personnelles :
Nom : Homme Frédéric BROUARD
Localisation : France

Informations professionnelles :
Activité : Expert SGBDR & SQL
Secteur : Conseil

Informations forums :
Inscription : mai 2002
Messages : 10 959
Points : 17 793
Points : 17 793
Citation:
1°) la première est que faire SELECT @OK=count(*)... pour savoir si le parent existe toujours n'est pas suffisant car l'enregistrement peut être modifié (bornes modifiées par exemple) ou supprimé entre temps quand on fait le SELECT @bgp=... suivant. Il faudrait faire un SELECT WITH HOLDLOCK (ou un SELECT FOR UPDATE en Oracle)
Non monsieur, il faudrait peut être comprendre ce qu'est le niveau d'isolation SERIALIZABLE (norme SQL) avant de dire des choses pareille.
Ce niveau d'isolation assure que les données seront stable pendant toute la transaction.
La seule chose qui importe est deonc la valeur de la clef que l'on veut mouvoir !
Faire un HOLDLOCK en plus est non seulement d'une grande bétise mais prouve que vous ne comprenez pas le concept de transaction et que vous ne maitrisez pas les verrous !
En l'occurence rajouter des verrous dans une transaction alors qu'on y pilote un niveau d'isolation qui fait que c'est le serveur qui décide des verrous à poser est franchement abérant et ne peut que conduire à une application pourrie !
Dans le principe on ne devrait JAMAIS utilsier directement les verrous.
En 15 ans de carrière dans l'informatique et an tant qu'expert en SQL et bases de données, je n'ai jamais eût besoin de le faire et cette technique intervallaire je l'ai expérimentée sur des volumes de données considérables en environnement à forte charge (plusieurs milliers d'utilisateur et réplication).

Citation:
2°) en conséquence du 1°) les UPDATE pour modifier les bornes peuvent être faux.
N'importe quoi !

Commencez par apprendre le SQL, mettez en pratique les bons conseils et évitez de douter des choses que vous ne maitrisez pas !

A +
__________________
Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
Site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
Blog SQL, SQL Server, modélisation données : http://blog.developpez.com/sqlpro
http://www.sqlspot.com : modélisation, conseils, audit, optimisation, formation
* * * * * Enseignant CNAM PACA - ISEN Toulon - CESI Aix en Provence * * * * *
SQLpro est déconnecté   Envoyer un message privé Réponse avec citation 00
Réponse Proposer ce sujet en actualité
Outils de la discussion



Fuseau horaire GMT +2. Il est actuellement 22h06.


 
 
 
 
Partenaires

Hébergement Web