Le portail francophone de la géomatique

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!

É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)