Tieni il profilo utente e utente in diverse tabelle?

Dipende dalle dimensioni e dai requisiti del tuo progetto.

Riesco a vedere un modo in cui i dati sugli utenti possono essere suddivisi in due set, con scopi diversi e quindi requisiti:

• Dati di identità: nome utente, hash della password, indirizzo email, ultimo orario di accesso, ecc.
• Dati del profilo utente, che includono le preferenze degli utenti, l'ultima attività, gli aggiornamenti di stato ecc.

Si noti che ci sono alcuni attributi sull'utente che possono rientrare in entrambe le categorie (ad esempio la data di nascita dell'utente). La differenza tra questi due set è che il primo è strettamente controllato e solo attraverso determinati flussi di lavoro può essere modificato. Ad esempio, la modifica di una password potrebbe richiedere la fornitura della password esistente, la modifica dell'email potrebbe richiedere la verifica della posta elettronica e sarebbe utilizzata nel caso in cui l'utente dimenticasse la password.

Le preferenze non richiedono tali ACL e potrebbero teoricamente essere modificate dall'utente o da un'altra applicazione a condizione che l'utente le acconsenta. La posta in gioco è bassa se un'applicazione maliziosamente o a causa di un bug corrompe i dati o tenta di modificarli (supponendo che vengano prese altre misure di sicurezza.) Tuttavia, di solito sarebbe disastroso se qualcuno dei nomi utente, password o email potesse essere modificato dal momento che possono essere utilizzati per assumere l'identità dell'utente o negare il servizio o causare costi di supporto ecc. per l'amministratore.

Pertanto, di solito i dati sono memorizzati in due tipi di sistemi:

• I dati di identità normalmente entrano in una directory o in una soluzione IAM.
• I dati delle preferenze finiranno in un database.

Detto questo, in pratica, le persone violano queste regole e usano l'una o l'altra (ad esempio, il server SQL dietro il provider di appartenenze ASP.NET).

Man mano che i dati dell'identità diventano più grandi o l'organizzazione che li utilizza diventa più grande, si insinuano diversi tipi di problemi. Ad esempio, nel caso della directory, tenterà di replicare immediatamente le modifiche della password a tutti i server in un multi-server ambiente. Tuttavia, la preferenza dell'utente richiede solo un'eventuale coerenza. (FYI: Entrambi questi sono diversi ottimizzazioni del teorema di CAPS.)

Infine, le directory (specialmente le directory online / cloud) invieranno anche token di accesso per altre risorse utilizzando protocolli come OAUTH (ad esempio, considerano Facebook, Google, Account Microsoft, ADFS), mentre un database non ha tale necessità. Un database supporterà join e struttura di query abbastanza complessi, di cui la directory non ha bisogno.

Per ulteriori dettagli, sarebbero utili alcune ricerche sulla directory delle identità e sul database.

Alla fine si riduce a quali sono i tuoi scenari e ci si aspetta che siano in futuro, inclusa l'integrazione con terze parti (e ciò che stanno usando). Se si tratta di un progetto ben contenuto e si è certi che è possibile proteggere i dati di identità degli utenti e autenticarsi correttamente, è possibile utilizzare il database. Altrimenti potrebbe valere la pena investigare su una directory di identità.

Se si va su DB, IMO, usando un DB contro due verrebbe alla fine il controllo degli accessi, sia per gli utenti che per le applicazioni.

Ci sono almeno tre casi in cui avere una tabella di persone per gli attributi di base e una seconda tabella per altri attributi con una relazione uno a uno è desiderabile:

• Dati BLOB come un'immagine. Una tabella separata consente di archiviare i dati separatamente per motivi di prestazioni, ad esempio in un tablespace separato.
• Dati che non si applicano a tutti o che si applicano solo a una persona che interpreta un determinato ruolo. Consideralo come colonne che sarebbero nulle in molte righe se facessero parte della tabella principale. Nel database di una clinica, puoi avere una tabella delle persone, una tabella paziente e una tabella medica, nel primo avresti attributi di base, nel secondo solo attributi pertinenti quando la persona è un paziente come copertura assicurativa, nel terzo tavolo (quando la persona è un medico) potresti avere la specialità medica e altri dati che si applica solo al personale medico. Ovviamente un medico può essere un paziente.
• Una tabella che materializza una relazione con un'entità in un sistema remoto. In questo caso la tabella stabilisce un'equivalenza tra identificatori univoci in un database separato per motivi di interoperabilità.

Penso che il caso che esponi si adatti al secondo caso.

La mia ragione principale per tenerli separati è cercare di evitare ciò che è noto nella programmazione orientata agli oggetti come una "classe di Dio". ORM associa tabelle e campi a classi e attributi, quindi diventa rilevante anche come livello SQL (anche senza un ORM esiste generalmente un principio simile in gioco).

La classe User (e per associazione la tabella utente) è frequentemente la tabella che diventa la classe di Dio con centinaia di attributi / campi, dozzine o centinaia di metodi e una definizione di classe (per i metodi) di oltre 1000 linee. Ho visto tutto. Più di una volta.

Quindi la separazione dell'utente prova a risolverlo. Ci possono essere persone, utenti, account e la separazione delle preoccupazioni può sembrare un po 'artificiale, ma è cercare di evitare la complessità e garantire che ogni oggetto sia interessato solo a 1 aspetto dei dati.