Normalizzazione del database e dipendenze

Question

Normalizzazione del database e dipendenze

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

8

Sto sviluppando 3-4 programmi interdipendenti. Chiamali foo bar baz e auth. Voglio che siano indipendenti l'uno dall'altro. Immagina se dovessi dare in licenza ciascun programma ad altre società. Alcune aziende potrebbero volere foo e bar, altre potrebbero semplicemente voler baz, ecc. Sembra anche una buona pratica mantenere anche l'auth indipendente.

Contesto: auth si sta prendendo cura dell'autenticazione per tutti i sistemi. La tabella utenti principale in auth ha user_id, email, password, first, last

foo ha anche una tabella utenti con campi specifici per l'applicazione: user_id, role_id, ecc.

Ogni sistema ha il proprio database. In passato ho creato una chiave esterna da ogni applicazione all'author db. Ho rimosso i permessi di aggiornamento dagli altri db ma ho concesso l'accesso selezionato ad alcuni campi rilevanti. Questa mi sembra una pessima soluzione perché crea una stretta dipendenza, ma mi ha permesso di normalizzare il db in modo da non dover memorizzare il nome e l'email degli utenti nei database foo, bar o baz.

Sarebbe meglio memorizzare le informazioni in tutti i database? O sarebbe meglio memorizzare l'id di Auth in foo bar e baz e usare un'API per ottenere le informazioni dell'utente usando authId?

Allo stesso modo, potrei avere clienti in tutti e 3 i sistemi. Certo, sembra dannoso creare una dipendenza in un'author db, ma che dire del dbs del cliente su tutti e 3?

O è la soluzione migliore per avere un database centrale. Una tabella utenti.

Altri suggerimenti?

architecture web-development dependencies normalization

posta ajon 15.05.2015 - 00:04

fonte

3 risposte

2

Il tuo esempio è un po 'astratto, ma lasciami scorrere i miei pensieri.

Opzione A: nella mia esperienza, questo è sempre negativo, indipendentemente dalle tue ragioni. certi DB come possono MSSQL avere database di amici, ecc, ma se i dati sono collegati, dovrebbe essere nello stesso DB

Opzione B: Non sai cosa sta succedendo qui, stai aggiungendo un'API che interroga tutti i DB e riunisce i risultati? Questo è meglio, ma se si dispone di App su quell'API, allora la sua parte del datalayer è per loro e in realtà usano solo uno dei DB, quindi perché hanno ottenuto gli altri nel loro livello dati?

Opzione C: Bene, funziona, ma non è bello avere un grande database con dati non correlati. Vuoi che i programmi siano indipendenti l'uno dall'altro giusto? questo non aiuta in questo.

Opzione D

Il mio suggerimento è di astrarre dall'autenticazione via il concetto di userId. la tua app di autenticazione dovrebbe riguardare utenti e ruoli (o promesse ecc se stai andando tutto moderno) questi dati dovrebbero esistere nel DB di autenticazione

Ogni app deve avere un ID utente per raggruppare i dati per utente, con alcuni dati correlati per effettuare la chiamata di autorizzazione e identificare l'utente per gli utenti. questo sarebbe userId (unico per l'app), vero nome, authusername, auth service da usare. Questi dati dovrebbero esistere nel DB delle app

I database non dovrebbero avere alcuna connessione tra loro, concettualmente dovresti essere in grado di usare Facebook come servizio di autenticazione piuttosto che la tua app di autenticazione

Potresti aver bisogno di ulteriori informazioni di collegamento per l'utente se vuoi mettere in relazione un utente foo con un utente della barra

risposta data 15.05.2015 - 11:14

fonte

0

Raccomando di implementare il Single Sign-On (SSO), ad esempio con LDAP. Probabilmente anche i tuoi clienti più grandi ne avrebbero beneficiato, dato che sarebbero stati in grado di sostituire l'app di autenticazione integrata con il proprio database utente esistente. Per i tuoi clienti più piccoli che non supportano SSO, puoi semplificare la distribuzione spedendo la tua app con un'app di autenticazione predefinita.

risposta data 17.05.2015 - 02:22

fonte

Leggi altre domande sui tag architecture web-development dependencies normalization

Algoritmo di raggruppamento In MVC un modello dovrebbe contenere modelli di subview?

score 4 · Accepted Answer

Se hai 4 servizi indipendenti, allora devono essere indipendenti. Nessun dato deve essere condiviso in DB comuni o simili, in quanto è sufficiente renderli dipendenti!

Ora, mentre è OK condividere un singolo DB in produzione, i servizi dovrebbero usare i propri schemi come DB è lì come un contenitore comune, simile a come un singolo server Linux può eseguire tutti e 4 i servizi.

Ogni servizio dovrebbe avere una propria API, e questo è l'unico modo per ottenere dati dentro e fuori da ciascuno. Quindi il tuo servizio di autenticazione archivierà gli utenti ed eseguirà l'autenticazione, ma restituirà alcuni token per identificare un utente. Questo token è ciò che gli altri servizi usano per ricordare quale utente è, ma altrimenti non dovrebbero avere alcuna conoscenza dell'autenticazione dell'utente.

Il modo più semplice per pensare all'implementazione di questi è pensare a cosa faresti se decidessi di utilizzare un servizio di terze parti invece di quelli che stai scrivendo - se hai usato il servizio OpenID di StackExchange per gli utenti invece che per il tuo. Se puoi sostituirlo nella tua architettura, allora hai un buon design indipendente.