Separazione della tabella utente dalla tabella persone in un database relazionale

Question

Ho realizzato molte app Web in cui la prima cosa da fare è creare una tabella utente con nomi utente, password, nomi, e-mail e tutti gli altri soliti relitti.Il mio progetto attuale presenta una situazione in cui i record non utenti devono funzionare in modo simile agli utenti, ma non hanno bisogno della capacità di essere un utente di primo ordine.

È ragionevole creare una seconda tabella, people_tb, ovvero la tabella relazionale principale e l'archivio dati, e utilizza solo il file users_tb per l'autenticazione?Fa la separazione user_tb da people_tb presenta qualche problema?Se questo viene fatto comunemente, quali sono le strategie, le soluzioni e gli svantaggi?

Answer 1

Questa è sicuramente una buona idea, poiché stai normalizzando il database.Ho realizzato un progetto simile in un'app che sto scrivendo, in cui ho una tabella dei dipendenti e una tabella degli utenti.Gli utenti possono provenire da un'azienda esterna o da un dipendente, quindi ho tabelle separate perché un dipendente è sempre un utente, ma un utente potrebbe non essere un dipendente.

Il problema che incontrerai è che ogni volta che utilizzi la tabella utente, vorrai quasi sempre che la tabella persona ottenga il nome o altri attributi comuni che vorresti visualizzare.

Dal punto di vista della codifica, se si utilizza SQL diretto, sarà necessario un piccolo sforzo in più per analizzare mentalmente l'istruzione select.Potrebbe essere un po' più complicato se stai utilizzando una libreria ORM.Non ho abbastanza esperienza con quelli.

Nella mia applicazione, lo scrivo in Ruby on Rails, quindi faccio costantemente cose come impiegato.nomeutente.nome, dove se li tenessi insieme, sarebbe solo nomeimpiegato.nomeutente.nome.utente.

Dal punto di vista delle prestazioni, stai raggiungendo due tavoli invece di uno, ma dati gli indici corretti, dovrebbe essere trascurabile.Se avessi un indice che contenesse la chiave primaria e il nome della persona, ad esempio, il database colpirebbe la tabella utente, quindi l'indice per la tabella persona (con un successo quasi diretto), quindi le prestazioni sarebbero quasi le stesse di avere un tavolo.

Potresti anche creare una vista nel database per mantenere entrambe le tabelle unite insieme per ottenere ulteriori miglioramenti delle prestazioni.So che nelle versioni successive di Oracle puoi persino inserire un indice in una vista, se necessario, per aumentare le prestazioni.

Answer 2

Lo faccio abitualmente perché per me il concetto di "utente" (nome utente, password, data di creazione, data dell'ultimo accesso) è diverso da "persona" (nome, indirizzo, telefono, e-mail).Uno degli svantaggi che potresti riscontrare è che le tue query spesso richiederanno più join per ottenere le informazioni che stai cercando.Se tutto quello che hai è un nome di accesso, dovrai unirti alla tabella "persone" per ottenere, ad esempio, il nome e il cognome.Se basi tutto sulla chiave primaria dell'ID utente, questo viene leggermente mitigato, ma viene comunque visualizzato.

Answer 3

Se user_tb ha informazioni di autenticazione, lo terrei separato da people_tb.Vorrei comunque mantenere una relazione tra i due e la maggior parte delle informazioni degli utenti verrebbero archiviate in people_tb tranne tutte le informazioni necessarie per l'autenticazione (che immagino non verranno utilizzate per molto altro) È un buon compromesso tra design ed efficienza i pensare.

Answer 4

Cerco sempre di evitare quanta più ripetizione possibile dei dati.Se non tutte le persone devono accedere, puoi avere un file generic people tabella con le informazioni che riguardano sia le persone che gli utenti (es.nome, cognome, ecc.).

Quindi per le persone che accedono, puoi avere un file users tabella con cui ha una relazione 1~1 people.Questa tabella può memorizzare il nome utente e la password.

Answer 5

Direi di optare per il design normalizzato (due tabelle) e denormalizzare (vai a una tabella utente/persona) solo se ti renderà davvero la vita più semplice in futuro.Se tuttavia praticamente tutte le persone sono anche utenti, potrebbe essere più semplice denormalizzare in anticipo.Tocca a voi;Ho utilizzato l'approccio normalizzato senza problemi.

Answer 6

Molto ragionevole.

Ad esempio, dai un'occhiata alle tabelle dei servizi aspnet_* Qui.

Il loro schema integrato ha un file aspnet_Users E aspnet_Membership con la tabella successiva che contiene informazioni più estese su un determinato utente (password con hash, ecc.) ma il file aspnet_User.UserID viene utilizzato nelle altre parti dello schema per l'integrità referenziale ecc.

In conclusione, è molto comune, e di buon design, avere attributi in una tabella separata se sono entità diverse, come nel tuo caso.

Answer 7

Questo è sicuramente ciò che facciamo poiché abbiamo milioni di record di persone e solo migliaia di utenti.Separiamo anche indirizzi, telefoni ed e-mail in tabelle relazionali poiché molte persone hanno più di una di ciascuna di queste cose.Fondamentale è non fare affidamento sul nome come identificatore poiché il nome non è univoco.Assicurati che le tabelle siano unite tramite un tipo di chiave surrogata (è preferibile un numero intero o un GUID) e non un nome.