Est-ce un-à-un rapport normalisé?

Question

Tenez compte que nous avons un grand ensemble de données statistiques pour un enregistrement; par exemple. 20-30 colonnes de INT. Est-il préférable de garder l'ensemble dans une table car ils appartiennent tous à un enregistrement ou la création d'une autre table liée à un-à-un.

L'avantage de l'ancien est d'éviter JOIN et avoir un accès rapide à toutes les données statistiques pour l'enregistrement correspondant.

L'avantage de ce dernier est de garder la rangée de colonnes. La première colonne est lue à haute intensité, et la seconde écriture à forte intensité. Bien sûr, je pense qu'il n'a pas d'effet significatif sur les performances, comme je l'utilise InnoDB avec blocage au niveau de la ligne.

En général, je veux savoir si elle est pratique utile de séparer les différents ensembles de données pour un seul enregistrement?

Answer 1

Si elle s'inscrit dans les règles de normalisation, puis 1: 1 Les relations peuvent être normalisées (par définition!) - En d'autres termes, il n'y a rien à 1: pour les 1 relations qui rendent impossible d'obéir aux formes normales.

Pour répondre à votre question sur l'aspect pratique de 1: 1 relations, il y a des moments où cela est une construction parfaitement utile, par exemple lorsque vous avez des sous-types distincts avec prédicats (colonnes)

.

Les raisons pour lesquelles vous utiliseriez 1: 1 relations dépendent de votre point de vue. CBM ont tendance à penser à tout comme une décision de performance. modélisateurs et les programmeurs données ont tendance à penser à ces décisions comme étant la conception ou orientée modèle. En fait, il y a beaucoup de chevauchement entre ces points de vue. Cela dépend de ce que vos perspectives et priorités. Voici quelques exemples de motivations pour 1: 1 relations:

• Vous avez un sous-ensemble de colonnes qui sont très larges et que vous voulez les séparer physiquement dans votre stockage pour des raisons de performance.

• Vous avez un sous-ensemble de colonnes qui ne sont pas lus ou mis à jour souvent et que vous voulez les garder à part les plus fréquemment utilisés colonnes pour des raisons de performance.

• Vous avez des colonnes qui sont facultatives en général, mais ils sont obligatoire quand vous savez que l'enregistrement est d'un certain type.

• Vous avez des colonnes qui appartiennent logiquement pour un sous-type et que vous voulez les modéliser pour bien cadrer avec le modèle objet de votre code.

• Vous avez des colonnes qui ne peuvent appliquer à certains sous-type (s) d'un entité super-type et que vous voulez que votre schéma pour faire respecter l'absence de ces données pour d'autres sous-types.

• Vous avez des colonnes qui appartiennent à une entité, mais vous devez protéger ces colonnes particulières en utilisant des règles d'accès plus restrictives (par exemple le salaire sur une table des employés).

Vous pouvez voir, parfois, le pilote est la performance, il est parfois la pureté du modèle, ou tout simplement le désir de profiter pleinement des règles de schéma déclaratives.

Answer 2

Les principales raisons pour lesquelles vous utiliseriez un-à-un pour briser une grande table en deux pour des raisons de performance, par exemple:

a) Le tableau contient des données binaires / clob / blob dans un tableau d'accès fréquent ralentissement par conséquent, les performances étant donné que les grandes colonnes sont traitées différemment.

b) Le tableau a de nombreuses colonnes qui sont accessibles par différentes requêtes, d'où la performance est dégradée donc vous déplacer des colonnes connexes dans un tableau distinct pour améliorer les performances d'accès

Cependant, avoir de colonnes entières ne justifie pas l'effort supplémentaire de briser la table dans des tables séparées et d'avoir à les interroger.