champs identiques dans la plupart des tables

Question

Dans un prototype de base de données, j'ai un ensemble de champs (comme le nom, la description, état) qui sont nécessaires dans de multiples tables fonctionnellement différentes.

Ces champs ont toujours les mêmes fonctionnalités d'utilisateur final pour l'étiquetage, l'affichage, la recherche, le filtrage, etc. Ils ne font pas partie d'une contrainte de clé étrangère. Comment cela devrait-il être modélisé?

je peux penser des variantes suivantes:

• Chaque table reçoit tous ces attributs. Dans ce cas, comment les nommeriez-vous? Le même, dans chaque tableau, ou avec un préfixe de nom de la table (comme usrname, ProdName)

• les déplacer dans une table des attributs, ajoutez une clé étrangère aux tables « de base », faisant référence Attributes.PK

• comme ci-dessus, mais au lieu d'une clé étrangère, utilisez le Attributes.PK comme PK dans la table de base respective ainsi.

Answer 1

il semble que vous pourriez prendre l'idée de la normalisation un peu trop loin. rappelez-vous, c'est l'idée que vous réduisez la redondance dans vos données . Votre exemple semble indiquer que vous vous inquiétez de la «redondance» dans les méta-informations de votre conception de base de données.

En fin de compte, user.name et user.description sont des fonctionnalités différentes de product.name et product.description, et doivent être traités comme tels. pour status, ça dépend de ce que vous voulez dire par là. est status juste un indicateur de l'enregistrement d'un produit/utilisateur étant actif ou non? Si c'est le cas, alors il serait logique de diviser cela en une table différente.

en utilisant les informations que vous avez fourni, si « actif/expiré/supprimé » est simplement une indication de l'état au sein de la base de données, alors je serais certainement d'accord avec une structure de table comme ceci:

users   products   status 
    id    id    id 
    name    name    name 
    description  description 
    status_id  status_id 

cependant, si status pourrait éventuellement être modifiée pour représenter quelque chose sémantiquement différent (par exemple, pour les utilisateurs, peut-être « actifs/retraités/Fired », je vous suggère de diviser que jusqu'à preuve la conception future:

user_status  product_status 
    id    id 
    name   name 

bref, normalise vos données, pas votre base de données desi gn.

Answer 2

Normalisation est souvent la meilleure pratique dans toute base de données relationnelle (dans des limites raisonnables). Si vous avez des champs comme state (c'est-à-dire l'état dans un pays), alors une table de référence comme "State" avec (id, short_name, long_name etc ...) pourrait être le chemin à parcourir, puis chaque enregistrement Les références d'un état n'ont besoin que d'une colonne state_id qui, comme vous l'avez mentionné, est une référence à un enregistrement dans la table State.

Cependant, dans certains cas, la normalisation de toutes les données ne sont pas nécessairement requis comme cela complique les choses simplement, mais il devrait être évident où le faire et où ne pas le faire.

Espérons que cela aide.

Answer 3

Sauf si vous utilisez le même nom ou la même description valeurs entre les tables, vous ne devez pas normaliser ces données. Les types de statut ont tendance à être réutilisés, donc, normaliser ceux-ci. Par exemple:

order_status_types 
- id 
- name 
- description 

shipping_accounts 
- id 
- name 
- description 

orders 
- order_status_type_id 
- shipping_account_id 

preferences 
- shipping_account_id 

Answer 4

Je donnerais à chaque table son propre ensemble de colonnes, même si elles ont les mêmes noms et sont logiquement similaires.

Si vous avez besoin de modifier l'une des tables en ajoutant ou en supprimant certaines de ces colonnes ou en changeant leur type de données, vous pouvez le faire uniquement dans la table correspondante, plutôt que de chercher à compliquer votre table d'attributs partagés.

Donner à chaque table le contrôle de ses propres attributs favorise Cohesion, ce qui est une bonne chose. Cela évite également de savoir dans quelle direction vont les clés étrangères.

En ce qui concerne la dénomination des colonnes, il n'est pas nécessaire ou souhaitable de placer des préfixes sur les noms de colonnes. Si vous effectuez une jointure qui aboutit à des colonnes du même nom provenant de deux tables, utilisez des alias pour les distinguer.

Answer 5

J'ai toujours donné à chaque table un code à 3 lettres que j'utilise ensuite dans tous les noms de champs. De cette façon, dans la table des produits, j'ai prdname, prddescription, prdstatus, et dans le fichier du vendeur j'ai venname, vendescription, venstatus. Lorsque les choses se rejoignent, il n'est pas nécessaire de s'inquiéter des mêmes champs nommés.

Bien sûr, les tables ont toutes un champ nommé id et la table de produit aurait un champ nommé venid qui fait référence au champ id dans la table du fournisseur. Dans ce cas, je ne mets pas le préfixe prd dessus car le venid est parfaitement logique et non ambigu.