#1 Wed 15 October 2008 13:05
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3175
- Site web
Arborescence et base de données
Bonjour,
Le message est peut-être un peu hors sujet concernant l'aspect spatial, mais je pense que l'info intéressera certains.
http://sqlpro.developpez.com/cours/arborescence/
A+
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#2 Wed 15 October 2008 13:57
- david_techer
- Juste Inscrit !
- Lieu: Antibes
- Date d'inscription: 22 Dec 2007
- Messages: 7
- Site web
Re: Arborescence et base de données
Merci pour le lien...!
Mais à nuancer dans le cas appliqué à PostgreSQL:
- énormément de contraintes (lourd en insertion?, surcharge en insertion?)
- beaucoup de mise à jour (UPDATE semblant très fréquents), si la taille de la table devient conséquente notamment de dernier niveau, un petit select en concurrence risque de prendre du temps si la table est en cours d'insertion
- gestion borne borne inférieur et supérieure pour une mise à jour assez difficile?
- !!SERIALIZABLE!!! (j(ai failli sauter au plafond!) C'est vrai que s'il faut rejouer des transactions mise en concurrence surtout en mode SERIALIZABLE, je veux bien voir les limites du modèle et surtout le dit cout du modèle dans une mise en production
A tester pour voir!
Hors ligne
#3 Wed 15 October 2008 19:11
- ChristopheV
- Membre
- Lieu: Ajaccio
- Date d'inscription: 7 Sep 2005
- Messages: 3175
- Site web
Re: Arborescence et base de données
Bonjour,
Je suis d'accord avec vos remarques, bien qu'étant débutant sous PostGrès. Mais pour ma part j'attaque le problème sous un autre angle, via un langage de programmation, la BD (sous ACCESS) ne servant que de fichier de stockage interrogé au travers de requêtes. Donc pour la problématique des insertions et mises à jour c'est beaucoup moins sensible, ceci étant réalisé par le code, à la limite cela passe par le chargement de la table existante, ajout d'éléments et ré indexation des bornes, puis inscription d'une nouvelle table. NB: je n'en suis qu'à l'esquisse du code.
A+
Christophe
L'avantage d'être une île c'est d'être une terre topologiquement close
Hors ligne
#4 Wed 22 October 2008 19:16
Re: Arborescence et base de données
Étant l'auteur du papier que vous citez, je me permets de vous signaler que j'ai mis en œuvre cette technique à de nombreuses reprises avant que les requêtes récursives de la norme SQL:1999, ne soient implémentés dans les principaux SGBDR sous la forme de CTE (Common table expression, voir mon papier à ce sujet : http://sqlpro.developpez.com/cours/sqls … ursives/). La première fois c'était sur une table comptant près de 400 000 lignes avec une profondeur d'arbre de 7 (nomenclature des références produits). Les temps de réponse étant tout à fait exceptionnel par rapport à un modèle en auto référence pour le SELECT (division par un facteur 1000 en moyenne). En revanche pour les mises à jour, nous avons eu une dégradation moyenne d'un facteur 2,5, ce qui reste marginal compte tenu que les insertions se font ligne à ligne.
Ayant utilisée cette technique à de multiples reprises, je puis vous affirmer que sur de bonnes bases (plusieurs centaines de milliers à plusieurs millions de lignes) et à condition de disposer des bons index (les bornes notamment doivent faire l'objet d'une indexation particulière) et d'y faire les bonnes requêtes. J'ai aussi entrepris pour l'un de mes clients une étude comparative qui montre que ce modèle est globalement le meilleur comparé à :
- modèle en auto référence
- modèle "path" (c'est à dire conservation du chemin dans chaque élément de l'arbre)
- utilisation de requêtes récursives
Néanmoins, sachez que l'éditeur Microsoft vient de réaliser dans l'édition 2008 de son SGBDR, un apport majeur constitué par le type hierarchyID dont le but est de faciliter les stockage et manipulations d'arborescences. Je n'ai pas encore procédé à une évaluation de cette nouvelle technique afin de la comparer, mais les premiers éléments dont je dispose montre qu'elle est au moins équivalente à la méthode intervallaire.
Enfin, sachez que dans ma présentation de la conférence Borland de 2003, je parle d'une amélioration sensible du modèle intervallaire permettant de limiter le coûts des mises à jour (http://sqlpro.developpez.com/cours/borcon2003/).
A +
Dernière modification par SQLpro (Wed 22 October 2008 19:19)
Frédéric BROUARD, Spécialiste modélisation, bases de données, optimisation, langage SQL.
Le site sur le langage SQL et les S.G.B.D. relationnels : http://sqlpro.developpez.com/
Expert MS SQL Server http://www.sqlspot.com : audits - optimisation - tuning - formation
<--- ===== ******* Enseignant au CNAM PACA et à l'ISEN à Toulon ******* ===== --->
Hors ligne
#5 Wed 22 October 2008 19:33
- david_techer
- Juste Inscrit !
- Lieu: Antibes
- Date d'inscription: 22 Dec 2007
- Messages: 7
- Site web
Re: Arborescence et base de données
Merci pour ce retour.
C'est surtout ce début de genre d'informations qui me manquaient, notamment l'insertion.
D'ailleurs nous sommes d'accord sur la politique d'indexation...!
Mais la description que vous fournissez reste (à mon sens) mono-transactionnel!
Combien pouvez-vous jouer en charge d'insertions en parallèles et pour un feed de combien de données?
Hors ligne