Quelle est la meilleure façon de modéliser les relations hiérarchiques définies par l'utilisateur dans une base de données?

Question

Pour l'essentiel, je veux que l'utilisateur soit en mesure de définir un modèle hiérarchique, mais je dois permettre à l'utilisateur de stocker des données dans leur modèle défini. Est-ce que ça a du sens? Ainsi, les utilisateurs seront en mesure de créer de nouveaux « types d'unités » qui seront organisés de manière hiérarchique et de décider comment les unités de ces types sont autorisés à organiser. Un exemple simple: dans mon interface hypothétique utilisateur crée trois types d'unités, le tronc, branches et feuilles. L'utilisateur définit alors les relations entre eux. Une feuille peut exister à tout moment dans la hiérarchie, une branche doit avoir un tronc en tant que parent. L'utilisateur peut alors créer des instances de ces types d'unités (en unités) et peut les organiser selon les règles définies dans leur modèle ... est-il un bon moyen de le faire dans la base de données?

Answer 1

Ceci est une question extrêmement large, mais vous pouvez pointer dans la bonne direction. Notez que vous n'allez pouvoir stocker les règles de relation dans la base de données. Sera les appliquer à votre code client. Essayez ceci sur la taille ..

unit:
    unit id,
    name,

unit relationship:
    unit id,
    foreign unit id

Vous pouvez alors utiliser votre table de relation de l'unité de la manière suivante ..

unit id se rapporte à l'unité, il est décrit. foreign unit id devrait être annulable.

A unit sans enregistrement de relation ne peut exister à la racine de la hiérarchie. Un unit avec un null de foreign unit id peut avoir toute autre unit comme parent. Dans le cas contraire, un unit doit avoir une autre unit comme parent, et il est le type doit être l'un de ceux qui sont définis dans ses dossiers de relations.

En ce qui concerne le stockage des cas eux-mêmes, qui devrait être simple ..

instance:
    instance id,
    unit id,
    parent instance_id

Je suis sûr qu'il y aurait d'autres champs que vous aurez besoin (nom, par exemple), mais je suppose que vous obtenez la dérive.

Answer 2

Vous devez mettre en œuvre trois concepts:

• les "types d'unités" et leurs associations autorisées
• la hiérarchie
• les unités réelles

Ces concepts peuvent coexister plus ou moins indépendamment dans le modèle, mais travailler ensemble.

create table unittype
(
    id int;
    name varchar(20);
)

create table unitrelationship
(
    id int;
    parent_id int;
)

Vous pouvez modéliser la hiérarchie comme tableau auto-référencement:

create table hierarchy
(
    id int;
    parent_id int;
    unit_type_id int;
    unit_id int;
)

Vous pouvez alors vos instances unitaires dans une ou plusieurs tables et faire avec eux ce que vous avez décrit.

create table unit
{
    id int;
    ....
}

Les bonnes nouvelles sont que vous Contraindre uniquement les types de parents autorisés, qui peuvent être facilement appliquées dans une interface utilisateur, par exemple en choisissant le parent d'une liste de toutes les unités existantes du type autorisé.

Answer 3

Je travaille sur un problème similaire même si je dois supporter plusieurs hiérarchies (un jeu d'enfants, des vues hiérarchiques multiples). Je l'ai trouvé « Les arbres et dans SQL pour Hiérarchies Smarties » Joe Celko (ISBN: 1558609202) utile. Je travaille toujours sur le problème, mais il arrive si souvent lors de la discussion à ce sujet qu'il a semblé opportun de mentionner.