L'applicazione SaaS Wingtip Tickets
Si applica a: 
database SQL di Azure
La stessa applicazione SaaS Wingtip Tickets viene implementata in ciascuno dei tre campioni. L'app è un semplice elenco di eventi e un'app SaaS di creazione di ticket destinati a piccoli locali: teatri, club e così via. Ogni locale è un tenant dell'app e ha i propri dati: dettagli del locale, elenchi di eventi, clienti, ordini di biglietti e così via. L'app, insieme agli script di gestione e alle esercitazioni, evidenzia uno scenario SaaS end-to-end. Sono inclusi i tenant di provisioning, il monitoraggio e la gestione delle prestazioni, la gestione dello schema e il reporting e analisi su più tenant.
Tre modelli di applicazione SaaS e tenancy
Sono disponibili tre versioni dell'app. Ognuna esplora un diverso modello di tenancy del database nel database SQL di Azure. Il primo usa un'applicazione autonoma per ogni tenant con il proprio database. Il secondo usa un'app multi-tenant con un database per ogni tenant. Il terzo esempio usa un'app multi-tenant con database multi-tenant partizionati.
Ogni esempio include il codice applicazione, gli script di gestione ed esercitazioni che esplorano una gamma di modelli di progettazione e gestione. Ogni campione si implementa in meno di cinque minuti. Tutti e tre possono essere distribuiti fianco a fianco in modo da poter vedere le differenze di gestione e progettazione.
Modello di applicazione autonoma per ogni tenant
Il modello di app autonoma per ogni tenant usa un'applicazione a tenant singolo con un database per ogni tenant. L'app di ciascun tenant, incluso il relativo database, viene implementata in un gruppo di risorse di Azure separato. Il gruppo di risorse può essere implementato nella sottoscrizione del provider di servizi o in quella del tenant ed essere gestito dall’operatore per conto del tenant. Il modello di applicazione autonoma per ogni tenant fornisce il massimo isolamento dei tenant, ma è in genere il più costoso perché non esiste alcuna possibilità di condividere le risorse tra più tenant. Questo modello è particolarmente adatto ad applicazioni che potrebbero essere più complesse e che vengono distribuite in un numero inferiore di tenant. Con le distribuzioni autonome, l'app può essere più facilmente personalizzata per ogni tenant rispetto ad altri modelli.
Vedere le esercitazioni e il codice su GitHub .../Microsoft/WingtipTicketsSaaS-StandaloneApp.
Modello con un database per ogni tenant
Il modello con un database per ogni tenant è utile per i provider di servizi che si occupano di isolamento dei tenant e vogliono eseguire un servizio centralizzato che consente un utilizzo efficiente delle risorse condivise. Viene creato un database per ogni locale di ritrovo, o tenant, e tutti i database sono gestiti centralmente. I database possono essere ospitati in pool elastici per offrire una gestione delle prestazioni economica e semplice, che sfrutta i modelli di carico di lavoro imprevisto dei tenant. Un database di catalogo contiene il mapping tra i tenant e i relativi database. Questo mapping viene gestito mediante le funzionalità di gestione mappe partizioni della libreria client dei database elastici, il che offre una gestione efficiente delle connessioni all'applicazione.
Vedere le esercitazioni e il codice in GitHub .../Microsoft/WingtipTicketsSaaS-DbPerTenant.
Modello con database multi-tenant partizionati
I database multi-tenant sono efficaci per i provider di servizi che cercano un costo per tenant inferiore e accettano un minore isolamento dei tenant. Questo modello consente di inserire un numero elevato di tenant in un unico database, riducendo il costo per tenant. Partizionando i tenant tra più database diventa possibile una scalabilità quasi infinita. Anche in questo caso un database di catalogo esegue il mapping dei tenant ai database.
Questo modello consente anche uno schema ibrido in cui è possibile ottimizzare i costi con più tenant in un database o ottimizzare l'isolamento con un singolo tenant nel proprio database. La scelta può essere effettuata tenant per tenant, quando viene eseguito il provisioning del tenant o in seguito, senza alcun impatto sull'applicazione. Questo modello può essere usato in modo efficace quando è necessario trattare in modo diverso i gruppi di tenant. Ad esempio, i tenant a basso costo possono essere assegnati a database condivisi, mentre i tenant premium possono essere assegnati ai propri database.
Vedere le esercitazioni e il codice su GitHub .../Microsoft/WingtipTicketsSaaS-MultiTenantDb.
Passaggi successivi
Descrizioni concettuali
- Una spiegazione più dettagliata dei modelli di tenancy dell'applicazione è disponibile nell'articolo Criteri di tenancy di database delle applicazioni SaaS multi-tenant
Esercitazioni e codice
Applicazione autonoma per ogni tenant:
Un database per ogni tenant:
Multi-tenant partizionati: