Discussion :

[zeb_zed]

Bonjour à tous,

Je développe un site dont le système est plus au moins similaire à disqus (système de commentaires avec pagination des commentaires)

Schématiquement:
une table item (plusieurs millions)
une table user (plusieurs millions)
une table comments (plusieurs millions) <== c'est là que je m'interroge

(mon environnement : PostgreSQL 9.1 + JPA Hibernate)

Je me demandais quelle pouvait être la meilleurs manière de persister en DB les informations de l'arbre des commentaires.

D'après ce lien:
Models for hierarchical data
Il existe 4 manières différentes de faire :
1 - "adjacency liste" : le plus commun, chaque noeud contient l'id de son parent
2 - "path énumération" : les chemins matérialisés
3 - nested set : arbre par représentation intervallaire
4 - closure table
5 - recursive CTE

Pour le 1 : cela implique des sous requêtes complexes et non performantes
Pour le 2 : ca me semble bien mais je crains que les requêtes sur des path avec des like % soit couteux
pour le 3 : l'idée est bonne mais dès que tu ajoutes un nœud il faut recalculer tous les autres, je pense que c'est une mauvaise idée pour des tables volumineuses et dont les insertions sont fréquentes (je table sur des millions de rows)
pour le 4 : ça semble idéal mais il y a peu de retour utilisateur et c'est surtout l'auteur de ce pattern qui en fait l'éloge donc j'ai des doutes (d'autant que j'ai l'impression que cette technique peut devenir très consommatrice en terme d'espace disque si l'arborescence est profonde)
pour le 5 : je sais que PostgreSQL supporte ça mais je ne pense pas que ça s'interface facilement avec Hibernate.

Je sais que d'autres solutions dérivées du nested set existent mais je n'ai pas la compétence pour juger de leur intérêt dans mon cas (entre autre : Nested Intervals Tree Encoding with Continued Fractions qui semble bien mais assez complexe à mettre en œuvre)

Bref, je ne sais pas quelle solution choisir parmi les 4 (même si je penche pour la 2 et la 4)

N'importe laquelle des solutions pourrait aller mais je dois choisir celle qui assure les meilleurs performances (table énorme et sollicitations très fréquentes) et une bonne maintenabilité.

vos avis et retours d'expériences sont les bienvenus

Merci

[SQLpro]

de toutes la meilleure solution est généralement l'arbre intervallaire, spécialement si le classement arborescent ne varie pas au fil du temps (pas d'update concernant les bornes de l’intervalle.

Lisez les articles que j'ai écrit à ce sujet :
http://sqlpro.developpez.com/cours/arborescence/
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 noter 1 et 5 reviennent au même...

A +

[zeb_zed]

Bonjour SQLpro,

Tes articles ont bien sur été le point de départ de ma réflexion

Cependant, malgré toutes les qualités des arbre intervallaires, je ne suis pas sur que c'est adapté dans mon cas (rappel: fort trafic et fort volume) car :
1 - j'ai des tables volumineuses (dès que tu ajoutes un nœud il faut recalculer tous les autres). De plus, je trouve qu'on perd le principe d'indépendance des rows du relationnel en recalculant les intervalles
2 - j'ai de nombreux accès concurrents (j'imagine que le recalcul des intervalles lors d'une insertion doit poser de nombreux verrous sur la base... pas glop)

[SQLpro]

Il faut être un peu plus malin... et ne pas oublier de penser...

1) le volume n'est pas important. J'ai mis en œuvre des arbres intervallaire testé au départ avec un millions de lignes et qui sont aujourd'hui sur plusieurs dizaines de millions. Plus l'arbre est profond et plus on est gagnant par rapport au modèle adjacent ou path
2) si tu as peur que la mise à jour soit bloquante, on peut au choix :
2.1) placer les composantes de l'arbre dans une table externe, et présenter une
vue
2.2) utiliser des intervalles décimaux qui ne propagent pas les updates. Cela s'apelle "Modélisation intervallaire par intercalage" (voir ma très ancienne présentation pour InterBase/FireBird : http://sqlpro.developpez.com/cours/borcon2003/)

A +

[zeb_zed]

Merci pour la qualité de ta réponse.

2.1) placer les composantes de l'arbre dans une table externe, et présenter une
vue

La perspective ne m'enchante guère... en tant que développeur java, j'ai tendance à effectuer la majorité du traitement coté applicatif et de ne pas laisser la base s'en charger, par manque de compétences dans ce domaine. J'ai aussi tendance à simplifier au maximum les choses et créer une vue pour résoudre un problème de mise à jour bloquante me parait un peu lourd à gérer.

2.2) utiliser des intervalles décimaux qui ne propagent pas les updates. Cela s'apelle "Modélisation intervallaire par intercalage" (voir ma très ancienne présentation pour InterBase/FireBird : http://sqlpro.developpez.com/cours/borcon2003/)

La perspective évoquée dans ta présentation est très séduisante
Ça rejoint l'article "Nested Intervals Tree Encoding with Continued Fractions" qui explique la mise en œuvre de ce principe. A première vue, ça semble assez complexe à mettre en œuvre. Et le requétage étant plus long en flottant qu'avec des numériques, je me dis autant utiliser dans ce cas des chemins matérialisés qui ont les mêmes avantages que la Modélisation intervallaire par intercalage sans la complexité apparente.

Également, il est difficile de récupérer uniquement les enfants d'un noeud avec les nested set ou les chemins matérialisés alors que les "closure table" le permette.
J'ai l'impression que les "closure table" permettent autant voir plus de souplesse que les nested set. Le recalcul des rows des nested set nécessite un update sur chacun des noeuds, soit un lock sur chacun des noeuds. Les closures table ne nécessitent qu'un insert donc pas de lock sur les noeuds (je dis peut être des bêtises, je ne suis pas compétant dans le mécanisme des verrous)

quelle dilemme!

[SQLpro]

NON, non, non et non !!! Vous commettez de nombreuses fautes dans votre raisonnement !

...
La perspective ne m'enchante guère... en tant que développeur java, j'ai tendance à effectuer la majorité du traitement coté applicatif et de ne pas laisser la base s'en charger,

C'est la pire de choses pour les performances. D'un coté vous demandez un conseil sur les perf. De l'autre vous allez détruire tous les axes de performances possible. Lisez l'article que j'ai écrit au sujet du style de dev.
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf
Si vous voulez des perf, me seule moyen est de mettre le maximum d'intelligence dans le base et le minimum du côté client; En effet un code client (donc itératif) n'est jamais optimisable dynamiquement, alors que c'est ce que pratiquent en permanence les bons SGBGDR du fait du code ensembliste, de l'indexation, de l'optimiseur et des contraintes !

par manque de compétences dans ce domaine. J'ai aussi tendance à simplifier au maximum les choses et créer une vue pour résoudre un problème de mise à jour bloquante me parait un peu lourd à gérer.

Manue de compétence, c'est hélas le point n°1 des mauvaises perf... quand on ne sait pas comment fonctionne un système quelconque il est impossible d'en tirer le meilleur partit !
De plus l'usage des vues est normalement impérative. Aucune application ne devrait attaquer directement les tables ! L'ensemble des vues et des routines (procédures, fonctions, déclencheurs...) con situant le MED (Modèle Externe de Données). Pensez simplement à ceci : que va t-il se passer une fois votre application écrite si il faut restructurer une table parce que les performance,ces ne sont pas bonnes ? Avec une vue, vous n'avez pas à récrire toute votre application. En utilisant un accès directe aux tables, vous êtes dans le merde....

La perspective évoquée dans ta présentation est très séduisante
Ça rejoint l'article "Nested Intervals Tree Encoding with Continued Fractions" qui explique la mise en œuvre de ce principe. A première vue, ça semble assez complexe à mettre en œuvre. Et le requétage étant plus long en flottant qu'avec des numériques,

Vous confondez entier et décimaux. En SQL il existe 3 types de nombres: les entiers (smallint, INT, BIGINT), les décimaux (DECIMAL, NUMEFRIC) et les réels (REAL, FLOAT). Vous ne devez surtout pas utiliser les réels car vous pourriez perdre définitivement certaines bornes du fait de l'imprécision des calculs en virgule flottante. C'est pourquoi SQL propose les décimaux qui ne sont pas entachés de ce problème

je me dis autant utiliser dans ce cas des chemins matérialisés qui ont les mêmes avantages que la Modélisation intervallaire par intercalage sans la complexité apparente.

Pas du tout !!!! Les performances d'une base de données relationnelle sont directement liées à la volumétrie et à la non redondance des informations. Avec ce modèle vous explosez les deux, à moins de trouver un moyen de compresser le path, comme le fait MS SQL Server depuis la version 2008 avec le type Hierarchyid (mais c'est toujours pas aussi bon que l'intervallaire).L

Également, il est difficile de récupérer uniquement les enfants d'un noeud avec les nested set ou les chemins matérialisés alors que les "closure table" le permette.
J'ai l'impression que les "closure table" permettent autant voir plus de souplesse que les nested set. Le recalcul des rows des nested set nécessite un update sur chacun des noeuds, soit un lock sur chacun des noeuds. Les closures table ne nécessitent qu'un insert donc pas de lock sur les noeuds (je dis peut être des bêtises, je ne suis pas compétant dans le mécanisme des verrous)

quelle dilemme!

Ne vous posez pas les problématique de verrouillage; C'est le SGBDR qui les gèrent au mieux en fonction notamment de :

• la granularité des informations à verrouiller
• de la nature de la transaction
• de la concurrence à l'instant t

le fait de déporter Les données intervallaire dans une table à part minimise encore plus ces verrous....

Le choix d'un bon SGBDR pour gérer cela est encore plus important. par exemple MySQL comme PostGreSQL ne sont pas réellement des SGBD relationnel dans le sens ou il ne sont pas capable de réaliser des traitements ensemblistes. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p1...d-relationn-1/
Pire, MySQL est farci de bug tous plus débiles les uns que les autres. A me lire : http://blog.developpez.com/sqlpro/p9...udre-aux-yeux/

A +

[zeb_zed]

Merci.

C'est la pire de choses pour les performances. D'un coté vous demandez un conseil sur les perf. De l'autre vous allez détruire tous les axes de performances possible. Lisez l'article que j'ai écrit au sujet du style de dev.
http://sqlpro.developpez.com/cours/b...s-epaisses.pdf
Si vous voulez des perf, me seule moyen est de mettre le maximum d'intelligence dans le base et le minimum du côté client; En effet un code client (donc itératif) n'est jamais optimisable dynamiquement, alors que c'est ce que pratiquent en permanence les bons SGBGDR du fait du code ensembliste, de l'indexation, de l'optimiseur et des contraintes !

L'article est très intéressant et avec un parti pris comme je les aime (je pense qu'il est nécessaire de prendre des positions tranchées pour faire avancer les technos, sinon on obtient des technos fumeuses qui s'imposent par le consensus de ne pas remettre en question les technos imposées de fait, je pense aux EJB, les connaisseurs comprendront...).
Même si je suis d'accord avec pleins de choses de l’article, j'ai du mal à adhérer à la vision selon laquelle tout le traitement métier doit être réalisé en base. Et même au contraire, la DB devrait pour moi n'assurer que les opérations d'intégrité référentielle, l'aspect transactionnel, le CRUD. C'est du coup réducteur pour toutes les possibilités offertes par les DB modernes mais je ne pense pas que parce qu'une DB sait faire tel ou tel chose, elle doit le faire systématiquement sous le seul prétexte des performances . A lire l'article, la couche application serveur ne servirait pas à grand chose et autant revenir au modèle client-serveur 2 tiers. Mais vous prêchez pour votre paroisse et moi pour la mienne et il est évident que le gain en performance de l'approche data-centrique est important mais ne justifie pas pour moi son emploi systématique puisqu'il y a d'autre aspects à prendre en compte : rapidité de développement, de déploiement, d'interopérabilité, sans compter les compétences spécifiques à tel ou tel DB nécessaires à l’approche data-centrique.
Les projets fortement orientés data-centrique sur lesquels j’ai travaillé ont toujours été pour moi très complexes à maintenir. C’est un argument que vous réfutez dans l’article en sous entendant que le temps de développement est réduit d’un facteur 2 à 3, c’est peut-être vrai quand on est un expert pl/SQL, mais dans la pratique…
Il est très facile de changer un ensemble de règles métier en java. J’ai des doutes avec les langages procéduraux.
Quant aux ORM, je suis en parti d'accord avec l'article mais un outil comme Hibernate doit être bien maitrisé pour que les requêtes soient optimisées. Un développeur débutant n'aura pas le réflexe d'utiliser des entités spécifiques ou des restrictions pour des requêtes bien optimisées, ce n'est pas une raison pour justifier son bannissement. En particulier, je n’ai pas de DDL à créer, mes classes java sont autoporteuses de la structure de la database, je trouve ça formidable.
Pour en revenir à la problématique de gestion des commentaires, je vais utiliser du SQL sans Hibernate et privilégier l’approche data-centrique pour tirer parti de tous les axes de performances des DB (je suis pragmatique, sur ce coup-là, les perfs sont un critère déterminant)

De plus l'usage des vues est normalement impérative. Aucune application ne devrait attaquer directement les tables ! L'ensemble des vues et des routines (procédures, fonctions, déclencheurs...) con situant le MED (Modèle Externe de Données). Pensez simplement à ceci : que va t-il se passer une fois votre application écrite si il faut restructurer une table parce que les performance,ces ne sont pas bonnes ? Avec une vue, vous n'avez pas à récrire toute votre application. En utilisant un accès directe aux tables, vous êtes dans le merde....

Changer les tables ou changer les DAO ou HBM, tel est la question…
En 15 ans de dev, je n’ai que rarement attaqué des vues SQL (je ne dis pas que c’est bien hein…), la considération des performances pures était souvent secondaire vis-à-vis du temps de dev (un scall up étant beaucoup moins couteux aujourd’hui qu’un développeur), de plus la plupart des projets ont des développeurs métiers qui ne se consacre qu’au développement métier sans penser aux optimisations DB (vues, triggers, etc) et un ou 2 DBA qui ne sont pas non plus forcément aptes à consacrer du temps à cela. Donc, l’aspect SGBDR épais aurait du mal à être déployé dans pas mal d’entreprises sauf à considérer que les développeurs Java, .Net soient également des développeurs pl/SQL, ce qui est rarement le cas.
Je pense que la tendance en entreprise est également de penser que la DB optimise et gère toute seule de la meilleur manière possible les requêtes et qu’il n’est pas nécessaire d’y passer du temps homme (ca rejoint un peu l’affirmation « Ne vous posez pas les problématiques de verrouillage »). Ce n’est pas pour ça qu’on ne pense jamais aux problématiques de performance non plus hein, mais c’est rarement la priorité.
C’est pour ça qu’on se rend souvent compte qu’après plusieurs mois en production, les performances se dégrade car on n’a pas pensé à cette problématique en amont (et c’est bien l’intérêt de mon message, connaitre le meilleur design)

Vous confondez entier et décimaux. En SQL il existe 3 types de nombres: les entiers (smallint, INT, BIGINT), les décimaux (DECIMAL, NUMEFRIC) et les réels (REAL, FLOAT). Vous ne devez surtout pas utiliser les réels car vous pourriez perdre définitivement certaines bornes du fait de l'imprécision des calculs en virgule flottante. C'est pourquoi SQL propose les décimaux qui ne sont pas entachés de ce problème

OK
J’ai quand même du mal avec l’arbre intervallaire…
Conceptuellement, le fait de devoir recalculer tous les nœuds lors d’un insert me gêne. Il n’y a pas d’intégrité référentielle avec ce système, ça pourrait être problématique en cas de restauration d’une partie de la table à un instant T ou de migration. Instinctivement, quelque chose me gêne. L’auteur du « closure table » désigne d’ailleurs les nested set comme un anti-pattern.
Pour la « modélisation intervallaire par intercalage », j’ai du mal à estimer la profondeur de l’arbre mais j’imagine que par dichotomie, ça ne doit pas aller bien loin. Avec 100 feuilles, les bornes doivent ressembler (grosse louche pour donner un ordre de grandeur) à 1 / 2 ^ 100, ça ne va pas loin (et peut être pour ça que cette solution est rarement évoquée)

Pas du tout !!!! Les performances d'une base de données relationnelle sont directement liées à la volumétrie et à la non redondance des informations. Avec ce modèle vous explosez les deux, à moins de trouver un moyen de compresser le path, comme le fait MS SQL Server depuis la version 2008 avec le type Hierarchyid (mais c'est toujours pas aussi bon que l'intervallaire).

Oui, mais outre le design des nested set qui me gêne, je trouve que le gain de performance lors d'une sélection (integer vs like %) ne justifie pas la complexité et les contraintes au niveau des insertions, suppressions, déplacements.
D’autant qu’on peut utiliser des BIGINT pour le path si la profondeur du tree n’est pas trop grande.

Je viens de trouver un article qui explique comment Disqus à schématiser sa DB :
http://justcramer.com/2012/04/08/usi...s-in-postgres/ (matérialized path)

Le choix d'un bon SGBDR pour gérer cela est encore plus important. par exemple MySQL comme PostGreSQL ne sont pas réellement des SGBD relationnel dans le sens ou il ne sont pas capable de réaliser des traitements ensemblistes. Lisez l'article que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p1...d-relationn-1/

Je connais ton opinion sur PostgreSQL puisque c’est à la lecture de ton article polémique que j’ai décidé de réfléchir en amont à l’optimisation de la DB.
PostgreSQL me convient (pas de transactions imbriquées mais je fais avec) et je ne peux me permettre d’acheter de l’Oracle (est-ce d’ailleurs nécessaire quand on n’envisage pas un base de données épaisse ?)
Pour MySQL, tu prêches un convaincu.
Merci encore.

[SQLpro]

...tout le traitement métier doit être réalisé en base...

Ne me faites pas dire ce que je n'ai pas dit. Je me base pas sur un concept idéologique comme la lutte des classes ou le positivisme logique... Bien qu'étant prof, je suis aussi un pragmatique, car mon revenu essentiel est d'implémenter des systèmes qui fonctionnent bien.

• Les SGBDR sont fait pour traiter des données ensemblistes (parallélisme, indexation, optimseurs... sont là pour ça)
• Les programmes informatique pour traiter des données unitaires de manière itérative

Partant de ce principe simple, les traitements seront plus efficace :
s'ils portent sur des ensembles de données, du côté du SGBDR
s'ils portent sur des données unitaires, du côté du code client itératif

... la DB devrait pour moi n'assurer que les opérations d'intégrité référentielle, l'aspect transactionnel, le CRUD.

Oui, mais jusqu’où placez vous le CRUD ? Relisez les règles de Codd et voyez ce qu'est une vue misajourable telle que décrite en règle 6 ici : http://sqlpro.developpez.com/SGBDR/ReglesCodd/

... l'approche data-centrique est important mais ne justifie pas pour moi son emploi systématique puisqu'il y a d'autre aspects à prendre en compte : rapidité de développement, de déploiement, d'interopérabilité...

le développement côté SQL est beaucoup plus rapide car plus concis. (en gros 4 fois moins de lignes à process équivalent) en sus moins de bug (4 fois moins de bug en moyenne car 4 fois moins de lignes).
le déploiement est instantané en SQL (le code SQL étant dynamique il s'applique immédiatement ALTER...) alors que tous les codes machine nécessite un arrêt d'exploitation
l’interopérabilité est plus vicieuse... En effet penser qu'en utilisant des trigger ou des procédures stockées rend impossible interopérabilité est tout à fait faux... C'est même strictement le contraire ! En effet il n'existe aucune requête SQL strictement compatible sur tous les SGBDR, sauf pour le SELECT * et à condition de ne pas avoir besoin de l'ordre des lignes de tri ! À me lire : http://sqlpro.developpez.com/cours/s...age=partie1#L3 dans l'exemple de requête 9, aucun des SGBDR ne sort le même ordre de lignes !!!!! Seule une procédure stockée peut rajouter par exemple l'appel d'une collation spécifique au SGBDR pour correspondre exactement à l’interopérabilité... En matière de conseil, j'ai toujours dit que pour avoir une interopérabilité parfaite, il fallait ne travailler que par vues et procédures et rein d'autre !!!

sans compter les compétences spécifiques à tel ou tel DB nécessaires à l’approche data-centrique.

Les SGBDR travaillent pratiquement tous de la même manière. Comme je l'ai dénoncé dans l'article que vous avez lu, le problème est essentiellement le manque de compétences du à la très mauvaise formation des ingénieurs... et croyez moi, je sais de quoi je parle, car j'enseigne dans 3 écoles d'ingé et même depuis quelques années je donne des cours aux autres prof qui pensaient encore naïvement qu'une SGBDR c'était du Excel amélioré !!!

En 15 ans de dev, je n’ai que rarement attaqué des vues SQL (je ne dis pas que c’est bien hein…), la considération des performances pures était souvent secondaire vis-à-vis du temps de dev (un scall up étant beaucoup moins couteux aujourd’hui qu’un développeur)

Là vous êtes dans le discours habituel et imbécile car à courte vue. En scale up les gains sont rarement supérieur à 10... En optimiation, les gains sont courramment entre 100 et 1000. Lisez l'article que j'ai écrit sur un exemple d'indexation... http://sqlpro.developpez.com/optimisation/indexation/

J’ai quand même du mal avec l’arbre intervallaire…
Conceptuellement, le fait de devoir recalculer tous les nœuds lors d’un insert me gêne. Il n’y a pas d’intégrité référentielle avec ce système, ça pourrait être problématique en cas de restauration d’une partie de la table à un instant T ou de migration.

Dans une transaction la mise à jour se fera en tout ou rien. L'intégrité de la base est donc toujours respectée. Vous confondez contraintes et transactions. Ce sont deux choses différentes !

Instinctivement, quelque chose me gêne. L’auteur du « closure table » désigne d’ailleurs les nested set comme un anti-pattern.

Tout cela ce sont des foutaises !!! Il n'y a pas de pattern en matière de modèle de données et vouloir comparer un langage objet avec ses limites avec un langage ensemblistes avec des spécificité est une imbécilité crasse !

Oui, mais outre le design des nested set qui me gêne, je trouve que le gain de performance lors d'une sélection (integer vs like %) ne justifie pas la complexité et les contraintes au niveau des insertions, suppressions, déplacements.

Une recherche d'entier est optimisable. pas un LIKE !

PostgreSQL me convient (pas de transactions imbriquées mais je fais avec) et je ne peux me permettre d’acheter de l’Oracle (est-ce d’ailleurs nécessaire quand on n’envisage pas un base de données épaisse ?)

Les transactions imbriquées, cela n'existe pas. C'est un concept. pas une réalité. En fait la transaction (unique et non imbriquée) existe ou n'existe pas....

Pour MySQL, tu prêches un convaincu.
Merci encore.

Pourquoi ne pas essayer MS SQL Server ? L'édition Express permet jusqu'à 32 000 bases de 10 Go.....

A +

[zeb_zed]

Je crois que nous n’arriverons pas à nous réconcilier hormis sur le constat que les développeurs ne savent pas mettre en œuvre les bonnes pratiques de conception pour gérer les BD. Et malheureusement, c’est compréhensible, car la somme de connaissances nécessaires pour mettre en œuvre ces bonnes pratiques est considérable et pas forcément du domaine de compétence du développeur métier ni même du DBA.
En somme, c’est presque du ressort d’un spécialiste SQL et des procédures stockées, rôle que peu de projets peuvent se permettre d’avoir. Et on ne peut pas demander à un développeur Java ou .Net d’avoir autant de savoirs académiques que toi. Après tout, chacun son domaine de compétence (et inversement, j’imagine qu’on ne te demande pas de connaitre toutes les JSR lorsque tu travailles sur des plateformes J2EE)
Tu dis que les SGDBR ne sont pas compatibles et tu évoques la possibilité de créer des vues et procédures (non portables tant qu’à faire), tu parles d’une interopérabilité…
Quitte à rajouter une couche d’abstraction pour l’interopérabilité, je préfère utiliser un ORM dont ça sera le rôle plutôt que de trafiquer des vues et des procédures (c’est un parti pris biaisé par ma profession qui vaut autant que ton parti pris sur les données épaisses)
Je maintiens que la considération des performances est souvent secondaire dans un projet (je ne dis pas que c’est bien, c’est juste un constat) et donc que le choix d’une approche BD épaisse ne se justifie pas systématiquement. De plus, l’argument selon lequel il y aurait moins de code est peu probable : d’une manière ou d’une autre, il faudra coder le traitement métier de contrôle et d’autres langages/frameworks que SQL sont sans doute plus appropriés pour cela.
Sans tomber dans les querelles de clochers, il faut être pragmatique et utiliser la solution la plus pertinente en fonction des besoins en laissant parfois un peu de côté l’aspect purement académique (rappelons-nous aussi que Facebook utilise une architecture LAMP, ce qui fait relativiser pas mal de choses…).

Donc pour en revenir au nested set, je vois plusieurs points négatifs en comparaison du materialised path :
- pas d’indépendance des lignes, ça a peu d’importance sur un petit arbre mais sur un arbre gigantesque, le cout d’insertion/modification/delete de nouveaux nœuds est loin d’être négligeable (non linéaire par la nature même du nested set). Si les insertions sont fréquentes, ça pourrait même être un sérieux point de contention (attente de la fin de transaction longue de recalcul pour chaque insertion). La solution par intercalage, outre sa complexité, ne conviendrait que si l’arbre est petit et peu profond, comme démontré dans mon précédent message
- pas de moyen de trouver facilement les fils d’un nœud (pas tout le sous arbre d’un nœud mais juste les fils)
- puisque le nested set consiste à enregistrer la pile à un instant T et que chaque row est dépendante des autres, un différentiel/restauration de base est très dure à établir.
- le materialised path peut utiliser des entiers si la profondeur de l’arbre n’est pas trop élevée
Mon avis est fait sur la question mais je ne vois pas pourquoi vous persistez à vanter le nested set eu égard aux inconvénients que je viens de lister (si ce n’est pour l’aspect purement démonstratif et original de cette technique)

Pourquoi ne pas essayer MS SQL Server ? L'édition Express permet jusqu'à 32 000 bases de 10 Go.....

Car je suis sous Linux, que j’ai le choix, que j’apprécie PostgtreSQL pour plein de raisons et qu’il me convient pour ce que j’ai à faire.

[vmolines]

Facebook n'a que peu de contrainte de cohérence ni de besoin d'isolation pour l'écriture de ses données.

[SQLpro]

Je ne vante pas le nested set, mais l'arbre intervallaire....
Point n'est besoin d'être spécialiste de SGBDR pour bien développer avec. En effet, des concepts simples sont à l'origine des bonnes bases. À me lire :
5 principes pour une base de données relationnelle performante
Les 10 meilleures pratiques pour développer avec un SGBDR

Il suffit au départ d'avoir correctement modélisée sa base en respectant au minimum les 3 premières formes normales.

Le reste coule de source....

Mais je préfère que vous fassiez le maximum de conneries, car cela me permet de vendre du service d'audit et d'optimisation qui conduit en général aux deux choses suivantes :
- refactoring de la base (nombreuses semaines ou mois de travail....)
- formation au développement avec les SGBDR
Mon tarif étant entre 1000 et 1600 € HT...

A +

[zeb_zed]

Point n'est besoin d'être spécialiste de SGBDR pour bien développer avec. En effet, des concepts simples sont à l'origine des bonnes bases. À me lire :
5 principes pour une base de données relationnelle performante

Je cite votre article :
2) PAS D’ANOMALIE TRANSACTIONNELLE : la modification d’une valeur sémantique doit se traduire par la modification d’une seule donnée dans une seule table. Sinon il faudra mettre à jour de nombreuses lignes et c’est doublement pénalisant : durée de la requête plus longue, et verrouillage de la table plus long empêchant la concurrence.

Ça va à l'encontre de l'arbre intervallaire et c'est bien un des points que je soulève dans ma précédente argumentation auquel vous n'apportez pas de contradictions.

Merci tout de même.

[SQLpro]

Mais ce ne sont pas des données sémantiques. Votre MCD peut vivre sans cette représentation... car ce sont des données techniques. C'est pourquoi la solution d'une table externe est souvent préférable...

A +

[StringBuilder]

Ce que veut dire SQL Pro, si je ne m'abuse, c'est qu'on peut parfaitement avoir :

Feuille
------
feuille_id (PK)
nom
trucmuche
ageducapitaine
couleurduchevalblancdhenriiv
etc.

Arbre
--------
feuille_id (PK et FK version feuille.feuille_id)
indice_gauche
indice_droite

=> Ceci permet d'avoir la table feuille "sémantique" qui est distincte de l'arbre. Ainsi, une modification dans une feuille ne touche qu'une seule ligne, on modifie des valeurs unitaires sans cascade.
=> Et pour l'arbre, on peut effectuer les mises à jour de façon par exemple asynchrone. Et même si elles sont synchrones, le fait de locker des pages de la table arbre pour mettre à jour les indice ne perturbera pas la lecture et l'écriture dans la table feuille, qui ne sera pas verrouillée.

[zeb_zed]

=> Et pour l'arbre, on peut effectuer les mises à jour de façon par exemple asynchrone. Et même si elles sont synchrones, le fait de locker des pages de la table arbre pour mettre à jour les indice ne perturbera pas la lecture et l'écriture dans la table feuille, qui ne sera pas verrouillée.

Ca ne résoud pas le problème de concurrence sur les insertions. Si l'arbre est très grand et nécessite la modification de grosso-modo la moitié des row de ta table "Arbre", on ne peut empêcher le point de contention des nombreux IO disques à chaque insertion, requête synchrone ou non.

C'est pour ça que je pense que l'arbre intervallaire n'est pas adapté à tous les cas d'utilisation et en particulier pas forcément à un système de commentaires dont les insertions sont nombreuses.
Si on ajoute que le materialized path avec bigint possède pratiquement tous les avantages des nested set sans ses inconvénients, je ne vois pas ce qui justifie une utilisation autre que dogmatique des nested set.

[SQLpro]

Un SGBDR digne de ce nom travaille exclusivement en RAM, pas sur le disque. Le disque n'est qu'un épiphénomène lié au fait que la RAM est volatile. Le nombre d'IO physique est donc très petit en regard des mise à jour logiques en RAM. Il n'y a donc pas de contention puisque les écritures de données sont asynchrones (par exemple toutes les minutes environ sur MS SQL Server) et pour les bons SGBDR comme Oracle ou SQL Server, les écritures sont regroupées par contiguïté d'emplacements physique sur les différents plateaux du disque. Si de plus il y a stockage parallélisé (exemple agrégat RAID) et que le SGBDR supporte les opération physique en // (SQL Sever, oracle) alors les écritures physiques sont ventilées et effectuées de manière simultané en fonction des espaces de stockage définis pour les base et pour chaque objet...

Visiblement vous avez encore de nombreuses choses à apprendre sur le fonctionnement d'un SGBDR !

A +