Utilizzo di un database per ciascun modulo in un sistema [duplicato]

Se vuoi combinare i dati di diversi moduli in qualsiasi modo, allora vuoi veramente un singolo database.

Il modo corretto per compartimentare le cose all'interno di un database consiste nell'usare schemi :

• Gli schemi hanno spazi dei nomi separati, quindi l'uso di uno schema per ciascun modulo garantisce che non ci saranno conflitti tra i moduli. email.table1 non si scontrerà mai con cms.table1 .
• Le autorizzazioni possono essere impostate a livello di schema, quindi il modulo email potrebbe essere autorizzato ad accedere alla sezione email, ad esempio.

Non penso che avere un singolo database creerà problemi per quanto riguarda l'installazione / la rimozione dei moduli. Non è davvero un grosso problema aggiungere e rimuovere tabelle / schemi in un database.

Per quanto riguarda le prestazioni, se si verificano problemi di prestazioni, in genere è necessario eseguire il drill down e vedere quali query causano comunque i problemi. Non penso che farà molta differenza se è in un database o più.

Se fatto correttamente, separando le preoccupazioni di business in diversi database (o almeno schemi diversi) è una virtù .

Consulta la descrizione di Martin Fowler del pattern CQRS :

As our needs become more sophisticated we steadily move away from [treating an information system like a CRUD datastore]... The change that CQRS introduces is to split that conceptual model into separate models for update and display... There's room for considerable variation here. The in-memory models may share the same database, in which case the database acts as the communication between the two models. However they may also use separate databases, effectively making the query-side's database by a real-time ReportingDatabase. In this case there needs to be some communication mechanism between the two models or their databases.

E Principi architettonici di NServiceBus :

Command Query Separation

A solution that avoids this problem separates commands and queries at the system-level, even above that of client and server. In this solution there are two "services" that span both client and server - one in charge of commands (create, update, delete), the other in charge of queries (read). These services communicate only via messages - one cannot access the database of the other...

E Comando e Query Responsibility Segregation (CQRS)

Command and Query Responsibility Segregation

Most applications reads data more frequently than they write data. Based on that statement, it would be a good idea to make a solution where easily you can add more databases to read from, right? So what if we set up a database dedicated just for reading? Even better; what if we design the database in a way so it’s faster to read from it? If you design your applications based on the patterns described in CQRS architecture, you will have a solution that is scalable and fast at reading data.

1. Sì, potrebbe essere un problema se si desidera analizzare più database contemporaneamente. È possibile migrare e unire tutti i dati in un unico database analisi e fare le analisi lì. Ciò significa che dovrai progettare uno schema che eviti qualsiasi scontro di nomi tra tabelle e altri oggetti e un processo per eseguire la migrazione, ma può essere fatto.
2. Sì, potrebbe anche essere un problema.
3. Sì, potrebbe anche essere un problema, anche se ogni modulo potrebbe anche avere una API di accesso ai dati per consentire ad altri l'accesso ai dati. Ciò renderebbe difficile avere query che si uniscono tra i database, ma sarebbe possibile. I collegamenti del database sono anche possibili in Oracle (consentono una query eseguita in un database accesso diretto agli oggetti in un altro), ma non posso parlare per i prodotti di altri fornitori.

E poi ci sono problemi di manutenzione extra di avere database separati per ogni modulo, come assicurarsi che siano tutti impostati correttamente, che tutti vengano sottoposti correttamente al backup, ecc ...

D'altra parte, se davvero si prevede di avere scenari in cui ci sono molti moduli e non sono tutti distribuiti tra loro, avere database separati potrebbe avere senso quando si impostano nuove distribuzioni. E aggiungere nuovi moduli potrebbe essere più semplice se si riesce a garantire che l'installazione non debba toccare alcun database esistente.