Progettazione del database: 4 tipi di utenti ma con funzionalità diverse, separate o una tabella?

Question

Progettazione del database: 4 tipi di utenti ma con funzionalità diverse, separate o una tabella?

#1 da (1 voti)
#2 da (0 voti)
#3 da (0 voti)

1

Ho 4 tipi di utenti:

Amministratori, utente normale, azienda , fornitore di servizi

Gli amministratori e gli utenti normali condividono alcuni attributi (id .primo nome, cognome, telefono, posta) azienda e fornitore di servizi condividono anche alcuni attributi (nome dell'azienda, telefono, fax, posta)

e interagiscono anche con altre entità nell'applicazione per accedere ad alcune funzionalità come post-lavoro o evento o richiedere la stessa

È meglio metterli tutti in un'unica tabella utente come tbl_users o è meglio creare una tabella separata per ognuno? oppure aggiungere a due tabelle una per (amministratore e utente normale) e altra per (azienda e fornitore di servizi)

e questo è alcuni dettagli sugli attributi di entità.

database data-structures database-design diagrams

posta ramyMorad 28.10.2014 - 15:51

fonte

3 risposte

Leggi altre domande sui tag database data-structures database-design diagrams

C # Iniezione inserimento dipendenza Aggiornamento dell'indirizzo IP per il dominio personalizzato [chiuso]

score 1 · Answer 1

Ciò che esponi dipende molto dalle esigenze della tua applicazione.

In genere si dissociano gli utenti dalle informazioni di contatto consentendo la massima flessibilità. Ti consiglio anche di ridimensionare i dati delle informazioni di contatto in un'unica tabella.

Utente (1,1) --- (0,1) Contact_Information

Azienda (1,1) --- (0,1) Contact_Information

Provider di servizi (1,1) --- (0,1) Contact_Information

La tabella utente includerebbe i dati di accesso e un campo aggiuntivo is_admin. L'esistenza di un collegamento tra due entità ti permetterebbe anche la flessibilità di una tale "persona reale" in grado di rappresentare sia un utente normale che un'azienda.

Ti consiglio anche di leggere come modellare l'ereditarietà in un database - > link

score 0 · Answer 2

Li terrei tutti in una tabella e aggiungo un campo per indicare che tipo di utente è. Avrai alcuni campi vuoti (ad esempio gli amministratori e gli utenti normali non hanno numeri di fax), ma questo non dovrebbe essere un problema a meno che tu non abbia molti utenti e alcuni campi vengano utilizzati solo per una piccolissima parte di essi . Puoi anche compilare gli spazi vuoti poiché non c'è motivo per cui i normali utenti non possano avere un numero di fax o perché i fornitori di servizi non possano avere nome e cognome.

Se necessario potresti avere una tabella "utenti" e una tabella "attributi utente" ma probabilmente non ne vale la pena per un numero limitato (ad esempio qualche centinaio) di utenti.

score 0 · Answer 3

A meno che i diversi tipi di utente non abbiano realmente ruoli diversi nello schema, tenerli in un'unica tabella. Avrei campi come il seguente:

Tipo di utente (utente, amministratore, azienda, fornitore)
Nome e cognome
Nome dell'azienda

Potrebbe essere sensato separare i numeri di telefono e gli indirizzi in altre tabelle, per consentire a un utente di avere molti numeri di telefono e indirizzi (forse un'azienda ha più uffici, un utente ha casa, cellulare, numeri di lavoro, ecc.) anche se tecnicamente non fa parte della domanda.

La cosa importante da ricordare è che un tipo utente è facilmente rappresentato come un campo su una tabella, consentendo ad altre tabelle di puntare a qualsiasi utente: questo impone un singolo tipo di relazione. Inoltre, gli utenti possono modificare i tipi senza dover mappare i dati tra le tabelle, aggiornare le chiavi esterne, ecc. Cosa succede se un utente normale diventa un amministratore? Che cosa succede se sta lavorando fuori di casa e incorpora, forse assume un lavoratore aggiuntivo? È abbastanza fattibile per gli utenti cambiare i tipi nel mondo reale, le tue regole di business possono essere diverse, naturalmente.