Multi-tenancy - database singolo o database multipli

Question

Multi-tenancy - database singolo o database multipli

#1 da (11 voti)
#2 da (10 voti)
#3 da (4 voti)
#4 da (3 voti)
#5 da (1 voti)

19

Abbiamo un numero di clienti, i cui sistemi condividono alcune funzionalità, ma hanno anche un certo grado di diversità. Il numero di clienti è in crescita - sempre una cosa salutare! - e anche la diversità tra le loro attività è in aumento.

Al momento esiste un singolo sito Web ASP.Net (Web Forms) (diversamente dal progetto web), che ha sottocartelle per ogni tenant, con le pagine non standard di quel tenant. Esiste un progetto di modello separato, che si occupa dell'accesso al database e della logica aziendale.

Quale è preferibile - e, soprattutto, perché - tra avere (a) 1 database per cliente, con solo le caratteristiche associate a quel client; oppure (b) un singolo database condiviso da tutti i client, in cui solo un sottoinsieme di tabelle viene utilizzato da qualsiasi client.

Le principali preoccupazioni all'interno dell'azienda sono finite:

manutenzione di più risorse - backup, controllo di versione e simili
promuovere il riutilizzo il più possibile

Come faresti a garantire che tali preoccupazioni vengano affrontate, quale soluzione è preferibile e perché? (Sto anche compilando le risposte a domande simili)

projects-and-solutions database-design multitenancy

posta RichardW1001 23.03.2012 - 22:07

fonte

5 risposte

Leggi altre domande sui tag projects-and-solutions database-design multitenancy

Quale convenzione di denominazione per il file C # che contiene più classi? È buona pratica utilizzare oggetti entità come oggetti di trasferimento dati?

score 11 · Answer 1

Ecco i punti salienti della ricerca di altre fonti (originariamente da revisione 2 della domanda ):

Devo utilizzare un database per applicazione o condividere un singolo database tra più applicazioni
Supporto della multitenancy
MSDN Architettura dei dati multi-tenant
SO Come creare un database multi-tenant con strutture di tabelle condivise?
CloudExpo SaaS - Opzioni di progettazione di database multi-tenant
Blog MSDN Passare al modello di database multi-tenant semplificato con le federazioni SQL Azure
Chiedi a SQL Server Central Un database o più?
SQL Server Central Mescolare tabelle da diversi database / applicazioni in un unico database
Blog di Ayende @ Rahien Multi Tenancy - Il modello dei dati fisici
Progetto codice Architettura di database multi-tenant
Joel su software Progettazione di database multi-tenant
SO Più applicazione utilizzando un database?
SO Database singoli o multipli
Code Rant - Multi-tenancy Parte 1, Strategia e Parte 2, componenti e contesto

score 10 · Answer 2

Se si utilizza SQL Server, utilizzare un database ma utilizzare schemi. Usa dbo per cose che sono generali per tutti i client e crea uno schema per ogni client e rendilo lo schema predefinito per gli utenti da quel client. Ora è possibile avere un oggetto generale (ad esempio un getBudget proc) nello schema dbo e uno personalizzato per il client nello schema con lo stesso nome.

score 4 · Answer 3

Poiché i database e le funzionalità dei client sono divergenti, significa che a un certo punto finiranno per essere sistemi diversi, quindi in questo caso consiglierei sistemi separati poiché i costi di mantenimento delle personalizzazioni per ciascun client supereranno i benefici di un singolo sistema di database.

I singoli sistemi di database sono i migliori per quando le modifiche tra clienti diversi sono solo configurazioni ma non funzionalità aggiuntive per ogni cliente.

score 3 · Answer 4

Ti mancano alcune preoccupazioni. I problemi arriveranno con la crescita. Se si può supporre che un giorno crescerai più di un server DB, un database complesso ti causerà sicuramente un mal di testa. A meno che non investiate in architettura in anticipo. Ma è anche un passaggio costoso)

Quindi, non dimenticare che è sia molte volte più economico e molte volte più semplice scalare pochi database diversi da quelli enormi)

score 1 · Answer 5

Un'area che non ho visto indirizzato nelle risposte è il problema con la protezione corretta di un'applicazione DB multi-tenant. Le app multi-tenant devono essere progettate con molta cura per evitare problemi di sicurezza. La maggior parte dei database e delle app forniscono un isolamento completo, ma non completo: esistono in genere modi per inferire direttamente o indirettamente i dati tra gli schemi DB. E molte risorse condivise (registri e altri file, tabelle DBA, cursori ...) che possono, per lo meno, portare ad attacchi di Denial of Service facili su altri tenant e in genere molto di più.