Utilisateur, client, compte administrateur dans 3 tables différentes?

Dans mon application web, j'aurai trois types de comptes.Utilisateur, client, compte administrateur dans 3 tables différentes?

utilisateur: pour utiliser l'application web gratuitement
Client: pour la publicité et l'obtention d'un logo de la société
Admin: pour des trucs d'édition et la suppression

Si tous ces trois être séparés tables ou dans une avec une colonne nommée "account_type" où je peux le marquer en tant qu'utilisateur, client ou administrateur?

Quels sont les avantages et les inconvénients pour les deux? Y a-t-il une meilleure pratique pour cela?

Merci

Source

2010-08-18 never_had_a_name

je pense qu'il serait utile de rester la façon dont les cas d'utilisation se rapportent à d'autres choses dans votre modèle de données. C'est à dire. quel est le lien entre Client et Images, Utilisateur/Admin en tant qu'accès. – Nix

Je dirais une table, mais s'il y a beaucoup d'attributs différents pour chaque rôle, vous devriez penser à des tables différentes. Vous pouvez marquer l'utilisateur avec un id/enum, appelons-le rôle. role = 1 serait un utilisateur, role = 2 serait un client et role = 3 serait un admin. Vous pouvez donc facilement étendre vos rôles avec une construction de clé étrangère (comme l'a dit David Stratton). – hering

En général, un person peut être utilisateur, client et admin -, je voudrais commencer par une table Person avec des colonnes IsCustomer, IsUser, IsAdmin. Plus tard (pour une recherche rapide), vous pouvez décider d'ajouter des tables séparées Admin, Customers, Users avec FK au tableau Person.

EDIT:

Un cas typique peut être:

5 millions d'utilisateurs
1000 clients
10 admins

En général, ayant des tables séparées pour les clients et Les administrateurs devraient accélérer toute requête liée à l'administration ou au client.

Source

2010-08-18 12:11:00

Parfois, les utilisateurs et les clients ont des propriétés différentes, vous devez donc les diviser en 2 tables au lieu de placer des colonnes facultatives dans la même table. – brunocascio

Si un utilisateur ne peut être un type, vous seriez mieux avec une table et un champ de bits pour IsAdministrator, etc.

Si un utilisateur peut être de plus d'un compte le type, vous devez alors une autre table avec une clé étrangère,

Structure

échantillon (Sypes de données sont SQL Server et suggéré seulement)

table utilisateurs

UserID - int
Nom d'utilisateur - varchar (25)
Mot de passe - varchar (25)
Prénom - varchar (50) etc ...

rôles Table

RoleId - int
Description du rôle - varchar (25)

User_Roles Table

UserId - int (avec une clé foregin à la table des utilisateurs)
RoleId int (clé étrangère à la table des rôles)

Source

2010-08-18 12:06:26 David

Je pense que je t'ai. Une table de compte pour les informations de base partagées par eux tous, puis 3 tables différentes pour chacun d'eux avec des informations spécifiques, puis je les lier avec une foreign_key dans le tableau de base droite? –

Ouais, vous le saviez déjà, – David

Je pensais que vous vouliez dire une table pour les administrateurs et une autre pour les clients avec toutes les informations répétées. Je l'ai mal lu, n'est-ce pas? – David

Avantages et inconvénients varient selon la taille et la complexité de votre système.

Je diviser en utilisateur, rôle, userresources

utilisateur (définirait des informations de base)

Rôles utilisateur

FK-> RoleType

Role_Type (utilisateur, administrateur, client, éventuellement autorisations ou vous pouvez le décomposer davantage).

userresources (médias)

> Utilisateur FK-

Source

2010-08-18 12:11:09 Nix

Utilisateur, client, compte administrateur dans 3 tables différentes?

Répondre

Questions connexes