Mantenere il profilo utente e utente in tabelle diverse?

Ho visto in un paio di progetti che gli sviluppatori preferiscono mantenere le informazioni utente essenziali in una tabella (email / login, hash password, nome schermo) e il resto del profilo utente non essenziale in un'altra (data di creazione, paese, ecc.). Per non essenziale intendo che questi dati sono necessari solo occasionalmente. Il vantaggio evidente è che se si utilizza ORM per la query di meno campi è ovviamente buono. Ma poi puoi avere due entità mappate sulla stessa tabella e questo ti salverà dalla query di cose che non ti servono (pur essendo più conveniente). Qualcuno sa qualche altro vantaggio di tenere queste cose in due tabelle?

Dipende dalle dimensioni e dai requisiti del progetto.

Vedo un modo in cui i dati sugli utenti possono essere divisi in due set, con scopi diversi e quindi requisiti:

• Dati identificativi: nome utente, hash password, indirizzo e-mail, ora dell'ultimo accesso, ecc.
• Dati del profilo utente, che includono le preferenze degli utenti, le ultime attività, gli aggiornamenti di stato ecc.

Si noti che ci sono alcuni attributi sull'utente che possono rientrare in entrambe le categorie (ad es. 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 di password esistente, la modifica dell'email potrebbe richiedere la verifica dell'email e verrà utilizzata nel caso in cui l'utente dimentichi la password.

Le preferenze non richiedono tali ACL e potrebbero teoricamente essere modificate dall'utente o da un'altra applicazione fintanto che l'utente lo acconsente. La posta in gioco è bassa se un'applicazione maliziosamente o a causa di un bug corrompe i dati o tenta di modificarli (presupponendo che vengano prese altre misure di sicurezza.) Tuttavia, di solito sarebbe disastroso se si potesse modificare il nome utente, la password o l'e-mail poiché 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 vengono archiviati in due tipi di sistemi:

• I dati di identità in genere vanno in una directory o in una soluzione IAM.
• I dati sulle preferenze finiranno in un database.

Detto questo, in pratica, le persone violeranno queste regole e useranno l'una o l'altra (es. Server SQL dietro il provider di appartenenze ASP.NET).

Man mano che i dati di 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 ambiente multi-server. Tuttavia, le preferenze dell'utente richiedono solo un'eventuale coerenza. (FYI: Entrambe sono ottimizzazioni diverse del teorema di CAPS.)

Infine, le directory (in particolare le directory online / cloud) rilasceranno anche token di accesso per altre risorse utilizzando protocolli come OAUTH (ad esempio, considera Facebook, Google, Account Microsoft, ADFS), mentre un database non ha tale necessità. Un database supporterà join e strutture di query piuttosto complesse, di cui non è necessaria la directory.

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

Alla fine si riduce a quali sono i tuoi scenari e dovrebbero essere in futuro, inclusa l'integrazione con terze parti (e ciò che stanno usando). Se si tratta di un progetto ben contenuto e sei sicuro di poter proteggere i dati di identità dell'utente e autenticarti correttamente, allora potresti scegliere il database. Altrimenti, potrebbe valere la pena indagare su una directory di identità.

Se scegli DB, IMO, l'utilizzo di un DB vs due finirà per ridurre il controllo degli accessi, sia per gli utenti che per le applicazioni.

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

• 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 ricopre un determinato ruolo. Pensalo 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 dei pazienti e una tabella dei medici, nel primo avresti attributi di base, nel secondo solo attributi pertinenti quando la persona è un paziente come la copertura assicurativa, in la terza tabella (quando la persona è un medico) potresti avere la specialità medica e altri dati che si applicano 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 identificativi univoci in un database separato per motivi di interoperabilità.

Penso che il caso che esponi rientri nel secondo caso.

Il mio motivo principale per tenerli separati è cercare di evitare ciò che è noto nella programmazione orientata agli oggetti come una "classe divina". Gli ORM mettono in relazione tabelle e campi con classi e attributi, quindi diventa rilevante anche come livello SQL (anche senza un ORM esiste un principio simile in generale).

La classe User (e per associazione la tabella degli utenti) è spesso la tabella che diventa la classe god con centinaia di attributi / campi, dozzine o centinaia di metodi e una definizione di classe (per i metodi) di oltre 1000 righe. Ho visto tutto. Più di una volta.

Quindi la separazione dell'utente tenta di risolverlo. Potrebbero esserci persone, utenti, account e la separazione delle preoccupazioni può sembrare un po 'artificiale, ma è per cercare di evitare la complessità e assicurarsi che ogni oggetto sia interessato solo a 1 aspetto dei dati.