Question

Je suis en train de mettre en œuvre un arbre comme la structure en utilisant un modèle de chemin matérialisé décrit ici: http://www.dbazine.com/oracle/or-articles/tropashko4 .

Est-il possible de faire respecter l'intégrité référentielle sur le champ [path]? Je ne vois pas comment SQL pouvait le faire, dois-je le faire manuellement dans le DAL?

Était-ce utile?

La solution

Oui, vous devez appliquer vous-même l'intégrité des données dans le DAL lorsque vous utilisez ou chemin matérialisé pour des solutions ensembles imbriqués données hiérarchiques.

Liste des contiguïté soutient l'intégrité référentielle, et cela est vrai aussi pour une conception que j'appelle « fermeture de table " (Tropashko appelle cette conception "relation de fermeture transitive").

Autres conseils

"chemin matérialisé" tel que présenté par Vadim Tropashko dans cet article, introduit la notion d'ordre dans une relation ( "Jones est le second élément.").

« chemin matérialisé » est rien « une certaine forme de vue matérialisée » sur la fermeture transitive, et souffre donc tous et exactement les mêmes problèmes que tout autre « vue matérialisée », sauf que les choses sont algorithmiquement pire précisément à cause de l'implication d'une fermeture.

SQL est presque complètement impuissants lorsque les contraintes-on-a-fermeture sont en jeu. (Signification: oui, SQL vous oblige à faire tout vous-même.) Il est l'un de ces domaines où le RM montre le maximum de sa puissance presque illimitée, mais SQL échoue lamentablement, et où il est dommage que la majorité des gens erreur SQL pour être relationnelle.

(@ Bill Karwin. Je voudrais pouvoir vous donner 1 pour votre remarque sur la relation entre la profondeur des arbres et le résultat sur la performance Il n'y a pas d'algorithmes connus pour calculer les fermetures qui fonctionnent bien dans le cas des arbres avec des profondeurs « fous ». Il est un problème algorithmique, pas un SQL ni relationnel.)

EDIT

Oui, RM = Modèle Relationnel

Dans le modèle de chemin matérialisé, vous pouvez utiliser des chaînes arbitraires (peut-être des chaînes unicode pour permettre plus de 256 enfants) au lieu de chaînes spéciales de forme « x.y.z ». L'identifiant du parent est alors l'identifiant des enfants directs avec le dernier caractère supprimé . Vous pouvez facilement appliquer cela avec une contrainte de vérification comme (mon exemple fonctionne dans PostgreSQL)

check(parent_id = substring(id from 1 for char_length(id)-1)),

au sein de votre commande create table. Si vous insistez sur les chaînes de la forme « x.y.z », vous devrez jouer avec des expressions régulières, mais je suppose qu'il est possible de trouver une contrainte de vérification correspondante.

Oui, nous pouvons « faire respecter l'intégrité référentielle sur le champ [path] ». Je l'ai fait il y a quelques années, décrit ici:

Stockez vos paramètres de configuration comme une hiérarchie dans une de base de données

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top