Utente, cliente, account amministratore in 3 diverse tabelle?

Nella mia applicazione web avrò tre tipi di account.Utente, cliente, account amministratore in 3 diverse tabelle?

utente: per utilizzare l'applicazione web gratuitamente
clienti: per la pubblicità e ottenere un logo aziendale
Amministrazione: per la modifica e l'eliminazione di roba

essere tutti questi tre in separata tabelle o in una con una colonna denominata "tipo_ccount" dove posso contrassegnarlo come Utente, Cliente o Amministratore?

Quali sono i pro e i contro per entrambi? C'è una buona pratica per questo?

Grazie

fonte

2010-08-18 never_had_a_name

penso che sarebbe utile per rimanere come i casi d'uso si riferiscono ad altre cose nel vostro modello di dati. Cioè qual è il collegamento tra Cliente e Immagini, Utente/Amministratore come accesso. – Nix

Direi una tabella, ma se ci sono molti attributi diversi per ogni ruolo, dovresti pensare a tabelle diverse. Puoi contrassegnare l'utente con un id/enum, chiamiamolo ruolo. role = 1 sarebbe un utente, role = 2 sarebbe un cliente e role = 3 sarebbe un amministratore. Quindi puoi facilmente estendere i tuoi ruoli con un costrutto di chiave esterna (come ha detto David Stratton). – hering

In generale, un person può essere user, clienti e admin - così, vorrei iniziare con una tabella con le colonne PersonIsCustomer, IsUser, IsAdmin. Successivamente (per la ricerca rapida) è possibile decidere di aggiungere tabelle separate Admin, Customers, Users con FK alla tabella Person.

EDIT:

Un caso tipico può essere:

5 milioni di utenti
1000 clienti
10 amministratori

In generale, con tabelle separate per clienti e gli amministratori dovrebbero accelerare qualsiasi richiesta relativa all'amministratore/cliente.

fonte

2010-08-18 12:11:00

A volte, utenti e clienti hanno proprietà differenti, quindi è necessario suddividerle in 2 tabelle anziché inserire colonne opzionali nella stessa tabella. – brunocascio

Se un utente può essere un solo tipo, che si starebbe meglio con una tabella e un campo di bit per IsAdministrator, ecc

Se un utente può essere di più di un account tipo, si dovrebbe quindi avere una tabella diversa con una chiave esterna,

struttura del campione (Sypes dati sono SQL Server e suggerito solo)

utenti tavolo

UserID - int
Nome utente - varchar (25)
password - varchar (25)
Cognome - varchar (50) ecc ...

ruoli tavolo

RoleId - int
Ruolo Descrizione - varchar tavolo (25)

User_Roles

UserId - int (con una chiave foregin alla tabella utenti)
ID ruolo int (chiave esterna alla tabella Ruoli)

fonte

2010-08-18 12:06:26 David

Penso di averti. Una tabella Account per le informazioni di base condivise da tutti, quindi 3 diverse tabelle per ognuna di esse con informazioni specifiche, quindi collego ad esse con una foreign_key nella tabella di base, giusto? –

Sì, lo sapevi già, – David

Stavo pensando che intendevi un tavolo per gli amministratori e un altro per i custmer con tutte le informazioni ripetute. Ho letto male, no? – David

Pro e Contro variano in base alle dimensioni e alla complessità del sistema.

avrei suddividerlo in uso, Ruolo, UserResources

utente (sarebbe definire le informazioni di base)

ruoli utente

FK-> RoleType

Role_Type (utente, amministratore, cliente, possibilmente autorizzazioni o si potrebbe risolvere ulteriormente).

UserResources (media)

FK-> User

fonte

2010-08-18 12:11:09 Nix

Utente, cliente, account amministratore in 3 diverse tabelle?

risposta

Problemi correlati