conception de base de données: colonne redondante vs colonne non utilisée

Question

Pour un projet en utilisant MySQL, j'ai un db qui ressemble à ceci:

Tableau 1: colonne A, colonne B, colonne C, colonne D.

tableau 2: colonne A, colonne B, colonne E, colonne F.

Comme vous pouvez le voir les colonnes A et B sont redondants à travers les tables (même type, même type d'information pour chaque table) .

Quelqu'un m'a suggéré de regrouper tout sous une table:

Tableau 1: colonne A, colonne B, C Colonne, Colonne D, Colonne E, Colonne F.

Le problème est que certains de mes articles utilisent les colonnes C et D et d'autres utilisent E et F, donc pour certaines lignes, ces colonnes seront toujours NULL.

Quelle est la pratique recommandée ici? Y a-t-il un design standard à suivre? Qu'en est-il des performances et des ressources (avec des milliers de lignes et ~ 10 tables)?

Un cas a colonnes redondantes et l'autre cas a colonnes non utilisées.

Ou peut-être que je pourrais partager les tables et créer une relation, il donne quelque chose comme:

Tableau 1: colonne A, colonne B.

Tableau 2: colonne A (clé étrangère), la colonne C, colonne D.

Tableau 3: colonne A (clé étrangère), la colonne E, colonne F.

Je suis un peu perdu ici. C'est nouveau pour moi. Merci pour toute contribution.

Answer 1

Si ce sont des relations 1-1, je les collerais dans une seule table pour faciliter l'utilisation. Il n'y a pas de vraie raison pour laquelle vous ne pouvez pas stocker NULLS dans la table. Personnellement, je préfère m'occuper de cela plutôt que d'avoir à gérer la synchronisation des clés entre les deux tables. Le seul avantage majeur que je peux voir en les séparant est que vous pouvez mettre des autorisations différentes sur les différentes tables si vous voulez contrôler le niveau d'information auquel un utilisateur donné a accès. Par exemple, la table A contient l'enregistrement de la personne principale et la table B contient les informations de contact. Bien sûr, vos comptes d'utilisateur standard peuvent y accéder, mais vous ne voulez probablement pas que chaque utilisateur ait accès à la table C qui contient les SSN des utilisateurs.

Si ce sont des relations 1-n, alors vous parlez de quelque chose de complètement différent, et il est clairement préférable de le diviser en plusieurs tables.

Answer 2

Cela dépend de votre comportement requête/écriture. Si vous mesurez des milliers de lignes comme vous le dites, cela ne fera pas une grande différence.

Il est peut-être préférable de planifier un schéma autour de ce qui est plus intuitif.De ce point de vue, je préfère voir des données redondantes dans deux tableaux, voir des valeurs nulles partout dans une table.

Answer 3

La réponse pas entièrement utile ici est "ça dépend". Vous devriez penser au delà de quelles colonnes les tables tiennent et considérer à quoi les tables seront employées.

Si vous allez extraire les données du Tableau 1 et du Tableau 2 et les présenter dans un seul espace, la clause where reflètera les valeurs de la Colonne A et de la Colonne B alors toutes les données dans une seule table fait le plus de sens.

Si vous ne voulez interroger qu'une seule table à la fois, il n'y a pas beaucoup d'avantages à avoir une seule table car vous essayez alors de faire une chose de deux choses. Si le nombre de colonnes "communes" entre les Tableaux 1 et 2 dépasse 2, diviser les tables et conserver les connaissances "spécifiques au domaine" dans les tables enfant est une excellente solution (voir les modèles de données "Parti") pour quelques exemples du monde CRM où c'est le cas).

La plupart des bases de données vont compresser des colonnes vides, il n'y a donc plus aucune raison physique de choisir l'une plutôt que l'autre.