Quand diviser des modèles en plusieurs tables de base de données?

Question

Je travaille avec Ruby on Rails, mais cette question est plus large que cela et s'applique généralement à la conception de base de données.

Quand est-ce une bonne idée de diviser un seul modèle en plusieurs tables? Par exemple, supposons que j'ai un modèle utilisateur et que le nombre de champs dans le modèle commence réellement à s'accumuler. Par exemple, l'utilisateur peut entrer son site Web, son anniversaire, son fuseau horaire, son etc

Y at-il un avantage ou un inconvénient à diviser le modèle, de sorte que peut-être la table utilisateur n'a que des informations de base comme la connexion et email, et puis il ya une autre table que chaque utilisateur a quelque chose comme UserInfo, et un autre qui est UserPermissions, et un autre qui est UserPrivacySettings ou quelque chose comme ça? Editer: Pour ajouter une note supplémentaire à ce sujet, la plupart des champs sont rarement accessibles, sauf sur les pages qui leur sont spécifiques. Par exemple, des éléments comme l'anniversaire ne sont accessibles que si un utilisateur clique sur le profil d'un utilisateur. De plus, certains champs (auxquels on accède rarement) peuvent être extrêmement volumineux. La plupart des champs ont le potentiel d'être soit blanc ou nul.

Answer 1

Ce serait une situation pour l'analyse.

Lorsque vous trouvez que beaucoup de champs dans une telle table sont NULLs, et peuvent être regroupés (par exemple. UserContactInfo), il est temps de regarder extraire les informations à sa propre table.

Vous souhaitez éviter d'avoir une table avec des dizaines/centaines de champs avec seulement des données à saisie éparse.

Essayez plutôt de regrouper les données de manière logique et de créer la table principale contenant les champs les plus peuplés. Ensuite, vous pouvez créer des sous-ensembles de données, presque comme vous les représenteriez sur l'interface utilisateur (informations de contact, intérêt personnel, informations relatives au travail, etc.) dans des tableaux séparés.

Answer 2

La récupération d'une ligne est plus coûteuse si elle comporte plusieurs colonnes, en particulier si vous avez généralement besoin de certains champs. En outre, l'hébergement de choses telles que les composants d'une adresse dans une classe séparée est un cas de DRY. D'un autre côté, si vous avez besoin de tous les champs d'un objet, il faut plus de temps pour exécuter une requête composée.

Je ne voudrais normalement pas distribuer des classes sur plusieurs tables juste pour rendre le code plus lisible (c'est-à-dire sans parties réellement réutilisables comme des adresses).

Answer 3

Généralement, il est recommandé de placer les éléments ayant une relation un-à-un dans la même table. À moins que votre base d'utilisateurs ne contienne l'ours Queen ou Paddington, un utilisateur a un seul anniversaire, ce qui devrait être un attribut de la table USERS. Les choses qui ont une relation un-à-plusieurs devraient être dans des tableaux séparés. Donc, si un utilisateur peut avoir plusieurs paramètres de confidentialité par tous les moyens les séparer. La division d'une table en plusieurs tables peut rendre les requêtes plus compliquées ou plus lentes, si nous voulons récupérer toutes les informations de l'utilisateur à la fois. D'un autre côté, si nous avons un ensemble d'attributs qui n'est jamais interrogé ou mis à jour de manière discrète, avoir une table distincte pour stocker ces données est une bonne idée.