Problème/défi de conception de base de données SQL Server

Question

J'ai une base de données qui a le noeud & tables nodetype.

Table des nœuds

NodeID 
ParentNodeID 
NodeTypeID 
NodeName 
... 

NodeType Tableau

NodeTypeID 
ParentNodeTypeID 
NodeTypeName 
..... 

Les deux tables ont une relation avec lui-même.

Il existe différents types de noeud-à-dire Noeud site bâtiment Bureau

Ce sont hiérarchiques, donc les informations (attributs) qui est appliqué à-dire les nœuds du site de type, devrait se propager vers le bas, et être Overridable par ses enfants.

Quelle est la meilleure façon d'y parvenir? Ou est-ce que je cherche à faire beaucoup dans SQL et devrait-il être traité dans le code?

MISE À JOUR

NodeID ParentNodeID NodeName Address1 Address2 Address3 NodeType NodeTypeID 
1   null   Top  null  null  MyTown Site  7 
2   1    Level1  null  HeadOffice MyTown Building 8 
3   2    Level2  SalesFloor HeadOffice MyTown Floor  9 

Answer 1

je ferais les suivantes

NodeTypes

NodeTypeId as INT 
ParentNodeTypeId as INT 
NodeDescription as VarChar (100) 

• liens ParentNodeTypeId à NodeTypeId pour une jointure réflexive

nœuds

NodeId as INT 
ParentNodeId as INT 
NodeTypeId as INT /* This field must be NULLABLE */ 
NodeDetails as VarChar (100) 

• liens ParentNodeId à NodeId pour une auto rejoindre
• liens NodeTypeId à NodeTypeId de la table NodeTypes, mais est annulable (lire)

j'aurais une fonction récursive appelée GetNodeTypeForNodeId (@NodeId as Integer) à comprendre le type de noeud.Si la ligne courante a une valeur non nulle, renvoyez la valeur courante, sinon augmentez la chaîne parent-nœud jusqu'à ce que vous trouviez un parent qui a une valeur non nulle. Notez que cela deviendrait extrêmement coûteux sur de grands ensembles de données. J'éviterais d'utiliser la fonction tant que mon ensemble de résultats n'aurait pas été complètement défini - en d'autres termes, j'utiliserais des sous-requêtes ou des CTE pour obtenir le filtrage de base, puis j'utiliserais la fonction pour obtenir le NodeType.

Answer 2

j'aurais tenir les NodeTypes qui sont spécifiques au nœud dans la base de données et gérer le déploiement d'NodeTypes dans la couche d'affaires. De cette façon, si quelque chose change sur un élément parent, il suffit de mettre à jour 1 enregistrement dans la base de données, pas un grand nombre (avec toutes les sous-mises à jour associées pour explorer la hiérarchie).

Answer 3

Je suppose que la table Node a également un NodeTypeID dessus? Sinon, je pense que la façon dont vous avez les données stockées est très bien. Le plus grand défi que vous rencontrerez consistera à déterminer quelles sont les propriétés «efficaces» d'un nœud/type de nœud en interrogeant ses propriétés, ses propriétés parentales, etc. Faire tout cela avec SQL serait probablement un cauchemar et il est probablement préférable de laisser l'accès aux données ou la couche de gestion de votre application où il serait beaucoup plus facile à implémenter.