Comment structurer ma base de données d'utilisateurs?

Question

J'ai un site Web qui permet aux utilisateurs d'être de différents types. Chacun de ces types peut faire des choses spécifiques. Je demande si je devrais mettre en place 1 table pour TOUS mes utilisateurs et stocker les types dans une énumération, ou devrais-je faire des tables différentes pour chaque type. Maintenant, si la seule chose différente était le type, il serait facile pour moi de choisir seulement en utilisant une table. Cependant, voici un scénario.

Les 4 utilisateurs sont A, B, C, D.

utilisateur A a données pour:

• Nom
• email

L'utilisateur B a données pour:

• nom
• email
• téléphone

utilisateur C a données pour:

• Nom
• email
• téléphone
• à propos

utilisateur D a données pour:

• Nom
• email
• téléphone
• à propos
• Adresse

Si je devais créer une seule table, si je laisse tout simplement différents champs null pour les différents utilisateurs? Ou devrais-je créer une table séparée pour chaque utilisateur?

Answer 1

Vous ne devez pas créer de tables pour des personnes différentes, car cela entraînera une base de données volumineuse. Il est préférable de créer une seule table avec tous les champs dont vous avez besoin. Si vous n'utilisez pas le champ, transmettez les valeurs nulles.

Answer 2

Beaucoup mieux si vous pouviez créer une seule table pour chacun d'eux. Bien que certains fichiers soient , ils peuvent être annulés. Et ajoutez une colonne supplémentaire (enum) pour chaque type d'utilisateur. Si vous conservez votre conception actuelle, vous devrez utiliser des jointures et unions pour les enregistrements. (qui ajoute une charge supplémentaire sur le serveur)

CREATE TABLE users 
(
    ID INT, 
    name VARCHAR(50), 
    email VARCHAR(50), 
    phone VARCHAR(50), 
    about VARCHAR(50), 
    address VARCHAR(50), 
    userType ENUM()   -- put types of user here 
) 

Une autre conception proposée est de créer deux tables, l'un pour l'utilisateur et l'autre est pour les types. L'avantage principal ici est quand vous avez un autre type d'utilisateur, vous n'avez pas besoin de modifier la table mais en ajoutant seulement un enregistrement supplémentaire sur la table de type d'utilisateur qui sera ensuite référencée par la table des utilisateurs.

CREATE TABLE UserType 
(
    ID INT PRIMARY KEY, 
    name VARCHAR(50) 
) 

CREATE TABLE users 
(
    ID INT, 
    name VARCHAR(50), 
    email VARCHAR(50), 
    phone VARCHAR(50), 
    about VARCHAR(50), 
    address VARCHAR(50), 
    TypeID INT, 
    CONSTRAINT rf_fk FOREIGN KEY (TypeID) REFERENCES UserType(ID) 
) 

Answer 3

Je suggère que vous utilisiez 1 table unique avec des champs NULLable. Et une table de quelque chose comme des rôles.

Answer 4

Essayez de créer quatre tables:

Table 1: Name, email 
Table 2: Name, phone 
Table 3: Name, about 
Table 4: Name, address 

Nom est votre clé primaire sur les quatre tables. Il n'y a pas de null dans la base de données. Vous n'êtes pas le stockage d'un type énuméré, mais déduire le type de jointures de table:

To find all User A select all records in table 1 not in table 2 
To find all User B select all records in table 2 not in table 3 
To find all User C select all records in table 3 not in table 4 
To find all User D select all records in table 4 

Answer 5

principes de conception de base de données de base suggèrent une table pour les éléments communs et des tableaux supplémentaires, ACCOLÉES à la table de base, pour les attributs unique à chaque type d'utilisateur.

Votre exemple suggère un et un seul champ supplémentaire par type d'utilisateur dans une hiérarchie d'héritage simple. Est-ce vraiment à quoi ressemblent les données, ou avez-vous simplement pour l'exemple? Si c'est une représentation fidèle de vos besoins, je pourrais être tenté (par opportunisme) d'utiliser une seule table. Mais si les vraies exigences sont plus complexes, je mordrais la balle et le ferais "correctement".