Est-il jamais judicieux de NE PAS condenser les relations une à une?


12

Si nous avons le tableau A qui a une relation un à un avec le tableau B, est-il jamais judicieux de les séparer? Ou cela ne fait-il jamais de mal de les combiner en une seule table? L'un ou l'autre de ces scénarios (deux tables contre une table combinée) a-t-il un impact sur sa forme normale (1NF, 2NF, 3NF, etc.)?


5
Voulez-vous dire 1 à 1 ou 1 à 0 ou 1?
jpmc26

Réponses:


30

Oui, il y a des tonnes de raisons pour lesquelles cela peut être la meilleure conception.

Vous pouvez avoir une relation d'héritage / extension, par exemple vous pourriez avoir une Usertable puis une Administratortable qui a plus de champs. Les deux tables peuvent avoir une clé primaire d'ID utilisateur (et donc avoir une relation 1: 1) mais tous les utilisateurs n'auront pas un enregistrement dans la Administratortable. Vous auriez besoin de quelque chose de similaire si vous soutenez un workflow, par exemple une ScheduledTasktable et une CompletedTasktable.

Vous voudrez peut-être avoir un tableau léger pour les données couramment utilisées User, puis un tableau plus grand pour les détails dont vous n'avez pas besoin très souvent UserDetails. Cela peut améliorer les performances, car vous pourrez insérer plus d'enregistrements dans une seule page de données.

Vous pouvez souhaiter des autorisations différentes sur les tables, par exemple UseretUserCredentials

Vous voudrez peut-être différentes stratégies de sauvegarde et donc mettre deux tables sur des partitions différentes, par exemple TransactionetTransactionArchive

Vous pouvez avoir besoin de plus de colonnes que ce qui peut être pris en charge dans une seule table, par exemple s'il y a beaucoup de grandes colonnes de texte que vous devez pouvoir indexer et que votre plate-forme de base de données est limitée aux pages de données 4K ou à quoi d'autre.


Si votre table contient plus de colonnes que ne peut le prendre en charge le système de base de données, vous avez un problème de conception. Mais sinon, votre réponse est valable.
Robert Harvey

2
D'accord ... J'essaie d'avoir une liste exhaustive, sans éditorialiser pour chaque raison.
John Wu

Quel est votre parcours dans les workflows? Avez-vous un logiciel spécifique que vous utilisez? Avez-vous déployé votre propre système de workflow?
Robert Harvey

1
Physique = ayant à voir avec des contraintes physiques telles que les performances du serveur, la taille de la page, l'indexation, la mise en cluster, les sauvegardes, etc., dont aucune ne devrait affecter la conception logique. D'un point de vue purement logique, une seule entité doit être conceptualisée comme un seul tuple ou ligne dans une seule table.
John Wu

4
Lien "Une relation un-à-un dans une base de données relationnelle se produit lorsqu'un enregistrement parent ou un champ n'a que zéro ou un enregistrement enfant uniquement."
John Wu

6

Ajoutant à l'excellente réponse de @ john-wu autre, une autre raison est lorsque vous avez un type de colonne BLOB comme une image.

Vous voulez que cette colonne BLOB dans une table distincte, non seulement pour les requêtes sur la table utilisateur soit plus rapide, mais aussi parce que vous pouvez déplacer la table contenant le blob vers un autre espace de table sur un stockage moins cher et plus lent, en conservant les données les plus interrogées dans le espace de table principal sur un stockage plus rapide.


3

Les relations un à un n'ont de sens que lorsque vous souhaitez que l'enregistrement associé dans le tableau B soit facultatif.

Parfois, ce que vous voulez, c'est un enregistrement de variante ou une union étiquetée . Cela signifie que vous disposez de plusieurs tables contenant des informations différentes, mais toutes se rapportant au tableau A dans des relations un à un. Vous choisissez ensuite la table à associer en fonction d'un champ du tableau A

Par exemple:

type Transaction(The_Type: PaymentType := Cash) is record

    Amount: Integer;

    case The_Type is
        when Cash =>
            Discount: boolean;
        when Check =>
            CheckNumber: Positive;
        when Credit =>
            CardNumber: String(1..5);
            Expiration: String(1..5);
    end case;
end record;

Si c'est facultatif, en quoi est-ce différent de tout cela dans une seule table et en sélectionnant simplement les colonnes que vous voulez?
Le 29 Saltshaker

Vous prenez le coût d'avoir ces champs supplémentaires dans la table principale, même s'il n'y a rien dedans. S'il existe plusieurs tables dans votre enregistrement de variante, vous pouvez avoir 100 colonnes dans une seule table, dont la plupart ne sont pas utilisées la plupart du temps.
Robert Harvey

2

Dans la modélisation métier, deux entités A et B qui sont logiquement distinctes d'un point de vue métier sont généralement mappées vers des tables différentes.

Par exemple, lorsque vous effectuez une modélisation métier avec des moyens orientés objet, vous disposez généralement d'une sorte de mappage relationnel-objet. Vous pouvez commencer avec un modèle d'objet et en dériver votre modèle relationnel. Imaginez donc dans votre modèle d'objet que vous avez créé les classes A et B qui, bien que les objets aient une correspondance 1: 1, devraient rester séparés en raison du principe de responsabilité unique . Notez que dans votre modèle d'objet, ces classes ne sont pas uniquement des tables avec des attributs, elles peuvent représenter des objets métier, avec un certain comportement implémenté dans les méthodes. Et lorsque vous mappez ces classes maintenant directement à un modèle relationnel, vous obtenez des tables A et B distinctes avec une relation 1: 1.

D'après mon expérience, lors de la création d'un modèle de données d'entreprise ou OO, cette séparation logique est beaucoup plus typique pour les relations 1: 1 que pour des raisons "physiques" comme les performances, la sécurité individuelle ou le partitionnement.


Pouvez-vous donner un exemple concret de ce que vous voulez dire?
Le 29 Saltshaker
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.