Je vais utiliser LLBLGen pour générer un modèle, mais je ne veux pas résoudre mes problèmes de conception en utilisant simplement les outils d'héritage intégrés dont il dispose. Je veux que le modèle ait du sens quel que soit l'outil OR/M. Donc, j'ai plusieurs types d'entités qui peuvent avoir des adresses et chaque entité peut avoir plusieurs adresses (primaire, mailing, etc.).Modélisation d'entités avec des choses en commun: super-type/sous-type?
Option 1, utilise un super type/Sous-type (Si vous connaissez le nom exact de ce genre de système, ce serait utile)
Tables: EntityType [EntityTypeID, EntityTypeName] (Say, Société = 1, employé = 2, AnotherEntity = 3)
Entité: [EntityID, EntityTypeID, OriginID]: EntityTypeID => EntityType
Société: [CompanyID, CompanyName, ...]
Employé: [EmployeeID, FirstName, ...]
AddressType: [AddressTypeID, AddressTypeName] (Say, primaire = 1, 2 = envoi, etc.)
Adresse: [AddressID, AddressTypeID, EntityID, StreetAddress1, ...]: AddressTypeID => AddressType, EntityID => Entité
La façon dont cela fonctionnerait est que, avant toute entreprise ou employé est créé, un dossier d'entité doit être créé avec EntityType rempli de façon appropriée. Ensuite, la société ou l'employé est créé et Entity.OriginID est défini sur l'ID de la société ou de l'employé. Maintenant, les enregistrements d'adresses appartiendraient aux enregistrements d'entités qui seront "liés" aux entités concrètes, voir l'EntityTypeID et l'OriginID.
Je suis un peu inquiet de toutes les jointures que cela nécessiterait. Et encore plus, je suis un peu inquiet que cela soit maladroit dans mon outil ORM (LLBLGen).
Option 2, cela prend en quelque sorte sur l'option 1. Je pense est probablement pire, mais y compris tout de même:
Tables:
EntityType: [EntityTypeID, EntityTypeName] (Say , Société = 1, employé = 2, AnotherEntity = 3)
Entité: [EntityID, EntityTypeID]: EntityTypeID => EntityType
Société: [CompanyID, EntityID, CompanyName, ...]: EntityID => Entité
Employé: [EmployeeID, EntityID, prenom ...]: EntityID => Entité
AddressType: [AddressTypeID, AddressTypeName] (Say, primaire = 1, 2 = envoi, etc.)
adresse: [AddressID, AddressTypeID, EntityID, StreetAddress1, ...] AddressTypeID => AddressType, EntityID => Entité
Cela fonctionnerait semblable à l'option 1, en ce que pour une entreprise ou un employé, un dossier Entité serait créé en premier, en définissant EntityType de manière appropriée.Ensuite, un enregistrement Société ou Employé serait créé et l'ID Entity de l'enregistrement entité précédemment créé serait défini dans l'enregistrement Société ou Employé lui-même. L'adresse serait liée à l'entité elle-même. Cependant, cela semble étrange car cela traiterait les enregistrements d'adresse comme les enregistrements Société et Employé, c'est-à-dire qu'ils contiennent un EntityID mais cette référence signifie quelque chose de différent que l'EntityID référence dans les tables Société et Employé.
Cela semble être un peu pire. Il a presque les mêmes problèmes que le premier mais il rend également le schéma moins intuitif, je pense. Dans les deux cas, vous devez utiliser des contraintes uniques, par exemple dans la table Company (EntityID doit être unique dans la table Company). Toutefois, vous devez effectuer une autre vérification programmatique pour empêcher un enregistrement Société et employé de pointer vers le même enregistrement d'entité. Je ne sais pas si un outil comme LLBLGen peut faire une "magie" avec l'option 1 en traitant intelligemment les valeurs EntityTypeID.
Ainsi, l'option 3 est simple:
Tables:
Société: [CompanyID, CompanyName, ...]
employé [EmployeeID, FirstName, ...]
AddressType: [AddressTypeID, AddressTypeName] (Dites, Primary = 1, Mailing = 2, etc.)
SociétéAdresse: [Compan yAddressID, AddressTypeID, CompanyID, StreetAddress1, ...]: AddressTypeID => AddressType, CompanyID => Entreprise
EmployeeAddress: [EmployeeAddressID, AddressTypeID, EmployeeID, StreetAddress1, ...]: AddressTypeID => AddressType, EmployeeID => Employé
Cela facilite grandement les jointures. Cependant, je ne pense pas que ce soit vraiment réalisable. J'ai beaucoup d'entités. Non seulement j'ai beaucoup d'entités mais j'ai beaucoup d'entités qui peuvent avoir une adresse. En outre, cette "adresse" des choses est juste un exemple, j'ai beaucoup d'autres sortes de choses qui sont similaires aux adresses. Je ne pense pas que la création d'une table pour chacun de ceux-ci évoluera très en termes de développement. Aussi, je suis sûr que je pourrais obtenir mon ORM pour me laisser utiliser le code pour traiter toutes les différentes adresses comme le même type d'adresse de base mais, encore une fois, je ne veux pas compter sur les astuces que l'ORM peut faire.
Alors, est-ce que ce type de super-type/sous-type est une bonne idée (je ne crois pas)? Si c'est le cas, y a-t-il une meilleure façon de procéder? Si non, quelles sont les meilleures alternatives.
Cela m'a aidé parce que vous m'avez donné le terme technique «spécialisation de généralisation». A partir de là, je pourrais regarder dans la documentation de LLBLGen et trouver exactement ce dont j'avais besoin. Thansk! – JustAProgrammer