Tuttavia, ci sono alcune aziende ovviamente che temono che i loro dati possano essere compromessi, quindi stiamo valutando altre soluzioni.
Questo è un peccato, poiché i clienti a volte soffrono dell'idea sbagliata che solo l'isolamento fisico possa offrire una sicurezza sufficiente.
C'è un interessante articolo MSDN, intitolato Architettura dati multi-tenant , che potresti voler controllare. Ecco come gli autori hanno affrontato l'idea sbagliata verso l'approccio condiviso:
Un malinteso comune sostiene che solo l'isolamento fisico può fornire un livello di sicurezza adeguato. In effetti, i dati archiviati utilizzando un approccio condiviso possono anche fornire una forte sicurezza dei dati, ma richiedono l'uso di modelli di progettazione più sofisticati.
Per quanto riguarda le considerazioni tecniche e commerciali, l'articolo fa una breve analisi su dove un determinato approccio potrebbe essere più appropriato di un altro:
Il numero, la natura e le esigenze dei tenant che prevedi di servire influiscono sulla decisione sull'architettura dei dati in modi diversi. Alcune delle seguenti domande potrebbero spingerti verso un approccio più isolato, mentre altre potrebbero spingerti verso un approccio più condiviso.
-
Quanti potenziali inquilini prevedi di prendere di mira? Potresti non essere nemmeno lontanamente in grado di stimare l'uso potenziale con autorità, ma pensa in termini di ordini di grandezza:stai costruendo un'applicazione per centinaia di inquilini? Migliaia? Decine di migliaia? Di più? Più ampia ti aspetti che sia la tua base di inquilini, più è probabile che tu voglia prendere in considerazione un approccio più condiviso.
-
Quanto spazio di archiviazione si prevede occupino i dati del tenant medio? Se si prevede che alcuni o tutti i tenant memorizzino quantità molto elevate di dati, è probabile che l'approccio a database separato sia il migliore. (In effetti, i requisiti di archiviazione dei dati potrebbero costringerti ad adottare comunque un modello di database separato. In tal caso, sarà molto più facile progettare l'applicazione in questo modo dall'inizio piuttosto che passare a un approccio di database separato in seguito.)
-
Quanti utenti finali simultanei ti aspetti che il tenant medio supporti? Maggiore è il numero, più appropriato sarà un approccio isolato per soddisfare i requisiti degli utenti finali.
-
Prevedi di offrire servizi a valore aggiunto per tenant, come backup e ripristino per tenant? Tali servizi sono più facili da offrire attraverso un approccio più isolato.
AGGIORNAMENTO: Ulteriore aggiornamento sul numero previsto di inquilini.
Il numero previsto di inquilini (10.000) dovrebbe escludere l'approccio multi-database, per la maggior parte, se non per tutti gli scenari. Non credo che ti piacerà l'idea di mantenere 10.000 istanze di database e di doverne creare centinaia di nuove ogni giorno.
Da quel parametro da solo, sembra che l'approccio con database condiviso e schema singolo sia il più adatto. Il fatto che archivierai solo circa 50 Mb per tenant e che non ci saranno componenti aggiuntivi per tenant rende questo approccio ancora più appropriato.
L'articolo MSDN sopra citato menziona tre modelli di sicurezza che affrontano considerazioni sulla sicurezza per l'approccio basato su database condivisi:
Quando sei sicuro delle misure di sicurezza dei dati della tua applicazione, sarai in grado di offrire ai tuoi clienti un accordo sul livello di servizio che fornisce forti garanzie di sicurezza dei dati. Nel tuo SLA, oltre alle garanzie, potresti anche descrivere le misure che adotteresti per garantire che i dati non siano compromessi.
AGGIORNAMENTO 2: A quanto pare i ragazzi di Microsoft hanno spostato/fatto un nuovo articolo su questo argomento, il link originale è sparito e questo è quello nuovo:Modelli di tenancy del database SaaS multi-tenant (complimenti a Shai Kerer)
