Database diverso per l'iscrizione e i nostri dati web o ne usi uno solo?

Il modo "normale" è di conservare tutto in un unico database. È solo un numero minore di pezzi mobili di cui tenere traccia nella propria applicazione. Puoi sempre spostare l'elenco dei membri nel proprio database in caso di necessità.

L'unica volta che li separerei dall'inizio è se il piano a lungo termine fosse che la lista di appartenenza risiedesse su un server separato fisicamente - forse in supporto di più applicazioni. Questo ti permetterebbe di affermare che il codice non stava facendo JOIN che non avrebbe funzionato in una tale configurazione.

Non sono rispettosamente in disaccordo con questa risposta . Avere dati diversi in database diversi sullo stesso server può fornire vantaggi significativi:

• Gli utenti possono "possedere" un database e avere il pieno controllo su di esso, ma essere altamente limitati o addirittura negare l'accesso del tutto nell'altro. Questa è una necessità virtuale per uno schema che governa la sicurezza delle applicazioni; l'account utilizzato per convalidare un utente dovrebbe essere in grado di fare non più o meno. Ciò che accedono con qui determinerà a cosa dovrebbero accedere nel database principale.

• Database diversi possono avere scopi diversi, diverse applicazioni di destinazione, richieste di prestazioni diverse e quindi design di schemi diversi. Uno schema potrebbe essere impostato per essere colpito rapidamente e duramente da una batteria di sistemi automatizzati che immettono dati grezzi; tabelle strette, profonde, in qualche modo denormalizzate ottimizzate per la pura velocità. Quindi un altro database potrebbe indirizzare le applicazioni utente e quindi avere una struttura più normalizzata in base alle esigenze di organizzazione, struttura gerarchica e integrità. Un mediatore può canalizzare i dati da uno all'altro, rispettando la necessità di velocità su un lato e producendo la struttura gerarchica normalizzata necessaria dall'altro.

• Mantenere separati gli schemi presi di mira da diverse applicazioni mantiene questi schemi, beh, separati. Una modifica necessaria per un'applicazione al suo schema non deve necessariamente influire su un'altra. Se gestisci una mezza dozzina di applicazioni utente diverse, ognuna con esigenze leggermente diverse, non dovresti assicurarti che una modifica a un'app non infranga nessuno degli altri cinque è enorme.

• Separare i DB per dati separati consente anche una migrazione molto più semplice. Supponiamo che tu abbia tre dipartimenti della tua attività in un edificio adibito a uffici a Chicago, ognuno dei quali utilizza un'app indirizzata a un DB in un server nella stanza sul retro. Quindi, trasferisci i servizi di helpdesk ad Abilene, perché è più economico. Il database richiesto dall'app helpdesk deve essere vicino ai computer dell'help desk geograficamente. Cosa è più facile? Creare un backup, inserirlo in un nuovo server in Abilene e puntare alcuni lavori di replica dei dati sul nuovo server su una VPN o una linea dedicata? Oppure, estrapolando una grossa fetta dello schema esistente, che potrebbe essere stato lasciato intrecciare con lo schema di altre app (poiché, sai, le tabelle si trovano nello stesso DB, quindi perché non impostare le chiavi esterne, giusto? ), impostando un nuovo database con quelle tabelle da zero, eseguendo la migrazione di tutti i dati, quindi testando tutte le app di tre reparti per la regressione?

• Separa DB significa schemi più piccoli significa backup più piccoli significa ripristini più veloci (e più granulari).

Più parti mobili possono essere, ma non è sempre una cosa negativa. È solo un problema quando le parti non si adattano bene, o non sono "ben oliate" e non si muovono in sincrono, o l'intera funzione dell'entità più grande dipende da questa piccola e delicata parte. Queste sono cose da prendere in considerazione, ma in nessun modo dovrebbero essere un deterrente per un modello di dati più distribuito.