Bon DB Table Design: une table mélangeant différentes entités ou table séparée pour chaque entité

Je dirai que toutes les réponses ci-dessus sont 1. CORRECT Compte tenu de l'exemple cité dans la question et 2. CORRECT pour presque tous le temps.

Chaque maintenant, je rencontre une situation où un seul la table est meilleure. Il est si peu fréquent que, quand il s'agit, je me demande si j'ai besoin d'architecte autour d'une entité monolithique (neutre) ou non. Je rejette rapidement l'envie - peut-être demander à quelqu'un d'autre, et je ne parviens pas à énoncer mes cas de manière adéquate et que nous retombons de la façon dont nous le faisons toujours. P>

Alors, comme il s'avère que tard dans le jeu, je trouve que j'aurais dû faire une table unique d'un type d'entité neutre. P>

Voici un exemple qui fait mon cas: p>

Supposons deux types d'entité, une société et une personne. Un Corp appartient généralement à une personne, mais parfois une autre société possède une société. P>

Tenir cette pensée et y ajouter, disons que chaque société a un agent enregistré responsable de la création légale. de la société. Et, en favorisant mon illustration, l'agent enregistré peut être une personne ou une autre société. P>

Étant donné que le propriétaire / parent à la société / enfant peut être une personne ou une amcorporation, vous pouvez commencer à voir le défi. En revanche, si seulement les personnes pouvaient posséder des sociétés, votre table de liens de propriété est très conventionnelle avec les colonnes: la propriété (en quelque sorte inutile), corporationded, personnage. P>

Au lieu de cela, vous avez besoin de quelque chose comme: Propriété, PROPRIÉTAIDED , Propriétaire Et d'une manière ou d'une autre, vous pouvez faire ce travail, mais ce ne sera pas amusant, de dire le moins. P>

Continuer avec l'exemple que j'ai donné, vous devez attribuer un agent à chaque société. Habituellement, l'agent est l'un des propriétaires (une personne). Dans ce cas, vous voulez vraiment vous relier à celui de cette personne. Vous ne voulez pas avoir enregistrement de la personne en tant que propriétaire, puis à nouveau en tant qu'agent (dans une table d'agent). Ce serait redondant. De mauvaises choses vont arriver. : -) p>

De même à ce "problème", un agent enregistré peut également être une société, telle qu'un cabinet d'avocats, une CPA ou une société de dépôt de BIG, appelant certains exemples typiques. Tout comme l'agent-personne, un agent-corporation ne devrait vraiment pas obtenir son propre dossier. Il faut relier à l'enregistrement déjà existant de son existence d'entreprise dans la table de la société. [Sauf que je dis que je dis que je dis en fin de compte pas em> avoir une table de société] p>

Tout comme la table de liaison correspondant à chaque société à son propriétaire de tout type, personne ou Corporation, vous pourriez-vous EM> avoir un agent de lien d'agent de: AgentRePresentationID, CorporationD, AgentID, Agenttype ... Mais à nouveau, ce serait laid (OMI) lorsque vous devez regrouper les agents associés - certains De la table de la personne, certaines de la table de la société. P>

Ainsi, dans ce cas, vous pouvez voir comment un type d'entité neutre peut être avantageux. Ce serait quelque chose comme ceci: P>

Table: Entitytall Colonnes de clé: Entitéïde, EntityType (ou entitéypeid Si vous insistez, liez-vous pour obtenir la description), EntityName (il y a des préoccupations avec des noms et des types différents ... hors sujet à ce poste) P>

Link Table: Personne de la corporation Colonnes de clé: La propriété (encore une fois, mon commentaire que c'est un peu inutile), Childentitéticulaire (l'entité appartenant à l'enfant; nommé "enfant" pour la clarté, je ne le nommerais pas que) Parententitéticulaire (l'entité parent) p>

Link Tableau: AgentRepresentation Colonnes de clé: Agentpresentationid (... je ne le dirai pas), CorporationtentikyID (l'entité CORP étant représentée), AGENTENTITYIDID (de la table d'entité, assimilé à l'enregistrement qui est l'agent ici) p>

Bien que vous puissiez être correct avec mon architecture, vous devez être un peu dérangé par la nommée de la colonne dans les tables de liaison. Ça me dérange. Généralement, les deuxième et troisième noms de colonne de ces tableaux correspondent exactement au nom des colonnes que vous rejoindre code> dans la table respective de chaque entité (haha, mais chaque entité ne a em> un em> respectif Tableau de sorte que vous ne pouvez pas avoir les noms de colonne de table de liaison correspondent aux noms de colonne source car ils sont la même colonne). Techniquement, cela n'a pas d'importance, mais cela brisera vos conventions de nommage qui devrait importer, mais pas suffisamment pour ne pas le faire. P>

au cas où je ne l'aurais pas poussé à la maison assez bien, voici comment tu es à quoi ll tire-le ensemble. Vous rejoindre code> l'entitéTall TABLE sur elle-même pour obtenir ce dont vous avez besoin. P>

Liste de tous les corps et de leurs propriétaires (en T-SQL): P>

SELECT Corp.EntityName as CorpName, Owner.EntityName as OwnerName
FROM EntityAll as Corp
JOIN CorporationOwnership as Link on (Corp.EntityID = Link.ChildEntityID)
JOIN EntityAll as Owner on (Link.ParentEntityID = Owner.EntityID)