comment concevoir un schéma où les colonnes d'une table ne sont pas fixes

Question

J'essaye de concevoir un schéma où les colonnes d'une table ne sont pas fixées. Ex: J'ai une table Employé où les colonnes de la table ne sont pas fixes et varient (les attributs de l'employé ne sont pas fixes et varient). L'ajout fréquent d'un nouvel attribut/colonne est une exigence.

1. colonnes nullables dans la table des employés lui-même-à-dire pas de normalisation

2. Au lieu d'ajouter des colonnes nullable, séparer les colonnes dans leurs tables individuelles ex: si l'adresse est une colonne à ajouter puis créer Adresse table [EmployeeId, AddressValue].

3. Créez des tables ExtensionColumnName [EmployeeId, ColumnName] et ExtensionColumnValue [EmployeeId, ColumnValue]. ExtensionColumnName aurait ColumnName comme "Address" et ExtensionColumnValue aurait ColumnValue comme valeur d'adresse.

   table des employés
   EMPLOYEEID
   Nom

   table ExtensionColumnName
   ColumnNameId
   EMPLOYEEID
   NomColonne

   table ExtensionColumnValue
   EMPLOYEEID
   ColumnNameId
   Col umnValue

Il y a un inconvénient dans les deux premières manières, car le schéma change avec chaque nouvel attribut. Notez que l'ajout d'un nouvel attribut est fréquent et une exigence.

Je ne suis pas sûr si c'est le bon ou le mauvais design. Si quelqu'un avait une décision similaire à faire, s'il vous plaît donner un aperçu sur des choses comme des clés étrangères/intégrité des données, l'indexation, la performance, des rapports, etc.

Answer 1

Je recommande d'utiliser une combinaison des numéros deux et trois. Dans la mesure du possible, modélisez les tableaux pour les associations standard comme les adresses. C'est l'approche la plus idéale ...

Mais pour en constante évolution des valeurs qui ne peuvent être résumées en groupes logiques comme cela, utilisez deux tables en plus de la table EMPLOYEES:

• EMPLOYEE_ATTRIBUTE_TYPE_CODES (deux colonnes, employee_attribute_type_code et description)
• EMPLOYEE_ATTRIBUTES (trois colonnes: employee_id clé étrangère aux employés, employee_attribute_type_code clé étrangère à EMPLOYEE_ATTRIBUTE_TYPE_CODES, et VALUE)

En EMPLOYEE_ATTRIBUTES, mis la clé primaire à citer:

• employee_id
• employee_attribute_type_code

Cela arrêtera les attributs en double au même employé.

Answer 2

Combinez vos tables ExtensionColumn dans un

Property: 
    EmployeeID foreign key 
    PropertyName string 
    PropertyValue string 

Si vous utilisez un séquence monotone pour affecter des clés primaires dans toutes vos tables d'objets, puis une seule table de propriétés peut contenir des propriétés pour tous les objets.

Answer 3

Il existe un motif, appelé motif d'observation.

Pour plus d'explications, voir ces questions/réponses: one, two, three.

En général, ressemble à ceci:

Par exemple, les sujets employés , compagnie et animaux peuvent tous avoir l'observation Nom (trait), les sujets employés et des animaux peut avoir observation Poids (mesure) et sujet bouteille de bière peut avoir des observations Étiquette (trait) et Volume (mesure). Tout va dans le modèle.

Answer 4

Il peut être utile de regarder la récolte actuelle de bases de données NoSQL qui vous permettent de stocker des ensembles arbitraires de paires clé-valeur par enregistrement.

Je vous recommande de regarder CouchDB, MongoDB, Lucene, etc ...

Si les modifications du schéma souvent dans une base de données SQL cela finit dans un cauchemar, en particulier avec des rapports.

Tout mettre dans les triades (rowId, key, value) est flexible, mais plus lent en raison du grand nombre d'enregistrements. De la même façon que les vendeurs ERP font leur schéma des champs dont ils sont sûrs et ajoutent un grand nombre de «flexfields» (20 chiffres, 20 chaînes, etc.) dans des colonnes nommées fixes et utilisent un table de recherche pour voir quelle flexcolumn correspond à quoi. Cela permet une certaine flexibilité pour l'avenir tout en ayant essentiellement un schéma statique.

Answer 5

Si, comme vous le dites, de nouveaux attributs seront ajoutés fréquemment, un modèle de données EAV peut fonctionner correctement pour vous.

Answer 6

J'utiliserais une combinaison de 1 et 2. Si vous ajoutez fréquemment des attributs, je ne pense pas que vous ayez un contrôle sur les exigences de données.

Je suppose que certains des attributs ajoutés appartiennent à une autre table. Si vous continuez à ajouter des attributs comme java certified, asp certified, ..., vous avez besoin d'une table de certification. Cela peut être lié à un tableau de codes de certifications répertoriant les certifications disponibles.

Des attributs tels que le gestionnaire peuvent être un attribut ou une table de relations. Si vous avez plusieurs relations entre employés, considérez une table de relations avec un type de relation. Les organisations ayant une structure de gestion matricielle auront besoin d'une table de releasation.

Les adresses et numéros de téléphone figurent souvent dans des tableaux distincts. Une clé d'adresse comme employee_id, address_type serait appropriée. Si l'historique est souhaité, ajoutez une colonne start_date à la clé.

Si vous conservez l'historique, je recommande d'utiliser les colonnes start_date et end_date dans les colonnes appropriées. J'essaie d'utiliser une relation où l'enregistrement est actif lorsque 'start_date < = date-considérée-< end_date' est vraie. Attributs comme le poids, la couleur des yeux, etc.