Meilleure pratique pour stocker des données arborescentes dans une base de données

Question

Je pense que la forme classique du problème est que vous avez des employés et que des employés ont des managers, de sorte que le manager a un manager à moins qu'il ne soit le PDG.

Alors, comment stockez-vous les données? Solution 1: Il semblerait que la table employee puisse avoir manager_id ou que vous puissiez avoir une table employee_manager (de cette façon, vous pouvez avoir plusieurs ou zéro managers). Certaines personnes disent que la solution 1 est une mauvaise idée car SQL ne prend pas en charge la récursivité et il n'y a pas de requête pour trouver tous les gestionnaires au-dessus d'un employé. Ces personnes ont des idées alternatives (comme l'employé a une liste de gestionnaires), mais ils semblent tous impliquer un tas de données non normalisées qui est extrêmement difficile à maintenir.

Alors, qu'en pensez-vous?

Answer 1

je suis d'accord avec d'autres .. récursion est disponible.

Je ne placerais pas le gestionnaire_id dans la table emp (malgré la sagesse antique SCOTT/TIGER). Le monde réel brise tout le temps cette règle commerciale et elle n'est pas bien normalisée. Pensez plutôt à une table de liens de type person_to_person, où deux personnes sont liées les unes aux autres pendant une période avec un rôle ... par exemple person1 est lié à person2 de janvier à mars en tant que manager. Cela vous permet une grande flexibilité dans l'affectation de personnes à des projets, des départements, des groupes arbitraires à travers le temps, même avec la réalité d'avoir plusieurs gestionnaires à certains moments dans le temps. Nous considérons également que les relations entre les personnes et les départements sont similaires - les personnes peuvent être liées de manière subtile à plusieurs départements en même temps.

Answer 2

Les bases de données SQL les plus courantes prennent en charge les requêtes récursives.

• La plupart des bases de données prennent en charge recursive CTEs.
• Oracle prend également en charge CONNECT BY.
• MySQL ne supporte pas non plus, malheureusement.

Answer 3

Certaines bases de données ont des requêtes récursives, comme la construction CONNECT BY dans Oracle. Dans ce cas, j'opterais certainement pour 1.

Mais même si ce n'est pas le cas, je pense que les données sont plus propres si vous donnez à chacun son propre manager, si c'est bien la structure des données. Vous devez exécuter plusieurs requêtes pour amener tous les gestionnaires au PDG, ou vous devez obtenir toutes les données et construire l'arborescence dans le langage de programmation que vous utilisez. Mais vous avez le même problème si chaque personne obtient une liste de gestionnaires. Vous aurez besoin d'une intelligence de programmation si vous voulez construire un arbre à partir de ces données. Sauf si vous avez Oracle, c'est. Au fait, je choisirais de faire une liste des départements et de donner un manager à chaque département. De cette façon, vous pouvez plus facilement mettre des personnes (même des managers) dans une position différente, sans avoir à mettre à jour les employés. Habituellement, les gestionnaires gèrent un ministère, alors ce ne sont que des gestionnaires d'autres personnes, parce que ces personnes travaillent dans ce ministère.

Answer 4

Vous devez décider où appliquer les contraintes d'intégrité de vos données et où les interroger/faire des choses intéressantes avec elles.

Comme d'autres l'ont mentionné, certains serveurs de base de données ne prennent pas en charge l'interrogation récursive; Cependant, si vous allez interroger la base de données, alors créez un arbre en code - alors c'est un point discutable.

Mais même si vous pouvez le faire en SQL - voulez-vous vraiment? SQL est parfait pour certaines choses, mais pas pour toutes les choses.

La principale préoccupation devrait être de laisser la base de données de faire ce qu'il est bon à - dans ce cas, des sons comme Solution 1.