Qui dovrai sopportare il fatto che forse ho trovato un po 'errata la terminologia in quanto non ero nemmeno consapevole che questo rientrava nella categoria "software multi-tenant" come "servizio", ma qui fa .SaaS multi-tenant PHP: separare i DB per ciascun cliente o raggrupparli?
Ho sviluppato un sistema di appartenenza (in PHP) per un client. Ora stiamo cercando di offrirlo come una soluzione completamente ospitata per i nostri altri clienti, fornendo un sottodominio (o anche il proprio dominio).
Le opzioni mi sembra di avere sul tavolo, per quanto riguarda l'archiviazione dei dati va sono:
Opzione 1 - Conservare tutto in 1 grande banca dati, e hanno un campo 'client_id' sui tavoli che hanno bisogno (ci sarebbero circa 30 tabelle a cui si applicherebbe), e avere una tabella "clienti" che memorizza le loro impostazioni principali, i dettagli, ecc. e il dominio per mapparli. Questo quindi imposta semplicemente una variabile accessibile a livello globale che contiene il proprio ID cliente individuale - Ovviamente dovrei modificare ogni singola query per verificare la colonna client_id.
Opzione 2 - Avere una tabella master con le tabelle di "riferimento condiviso" e la tabella "clienti". Quindi hanno 'blocchi' di altri database, che contengono ciascuno, ad esempio 10 client. Il cliente otterrebbe le proprie tabelle di database, precedute dal loro ID cliente. Questo aggiunge un po 'di sicurezza per proteggere dal vedere altri dati del client se qualcosa è andato veramente male.
Opzione 3 - Esattamente come l'opzione 2, tranne che si dispone di 1 database per ogni cliente, completamente isolandoli da altri client, e fornendo teoricamente un po 'più di protezione che, se le tabelle 1 del cliente sono stati violati o in altro modo danneggiato, non influenzerebbe nessun altro. Lo svantaggio più grande è che quando si distribuisce un nuovo client, è necessario impostare un intero database, utente e password, ecc. Ciò potrebbe anche causare una notevole quantità di spese generali, o sarebbe praticamente lo stesso come se si avessero tutti in uno Banca dati?
Anche alcuni punti - alcuni di questi clienti avranno oltre 5000 "clienti" e tutti i dettagli per questi clienti - ecco perché l'opzione 1 potrebbe essere un po 'problematica - se ho 100 clienti , che potrebbe equivalere a oltre mezzo milione di righe in 1 tabella.
Sono corretto nel pensare che l'opzione 3 sarebbe il modo migliore per andare in una situazione in cui la sicurezza dei dati dei clienti (e le informazioni di pagamento) è la chiave. Dalle raccomandazioni che ho avuto, alcune persone hanno detto di andare con l'opzione 1 perché "è più facile", ma in realtà non la vedo così. Lo vedo come un potenziale collo di bottiglia lungo la linea, in quanto sicuramente posso spostare i clienti molto più facilmente se hanno il loro database.
(FYI Il sistema è basato su PHP e MySQL)
Grazie Ozzy - anche questo è stato il mio pensiero. L'unico svantaggio potenziale, sebbene non sia uno dei maggiori, sta spingendo gli aggiornamenti delle tabelle a tutti i database. Tuttavia, poiché tutti i DB eseguiranno lo stesso set di tabelle, con la stessa identica struttura, in teoria avrei pensato che fosse possibile creare uno script semplice per scorrere tutti i dettagli del DB, connettersi, eseguire la query di aggiornamento, disconnettersi e passare a il prossimo DB. – Sk446