Esplosione di bolle: passare a un'architettura multi-tenant è un aspetto ortogonale dell'utilizzo di OOP all'interno del codice. Sì, è necessario aggiornare il codice dell'applicazione, ma non è necessario modificare lo stile generale della programmazione.
E ora , per una risposta effettiva:
Esistono tre ampi approcci per passare a un ambiente multi-tenant. Penso che tu voglia l'approccio blended per risolvere il tuo problema. Rappresenta il miglior equilibrio tra il sovraccarico amministrativo del sistema; codice aggiuntivo da scrivere; e manutenzione del database.
L'approccio misto consiste nell'utilizzare un singolo schema condiviso che ha autorizzazione controlla per controllare l'accesso ai dati.
Il modo più semplice per ottenere questa multitenancy combinata consiste nell'aggiungere una colonna che rappresenta la proprietà alle varie tabelle del database che richiedono il controllo dell'accesso. Dovrai anche creare una tabella delle autorizzazioni se non ne hai già una che colleghi utenti o gruppi agli ID proprietario del database a cui sono autorizzati ad accedere.
All'interno della tua applicazione, le tue domande dovranno essere aggiornate per riflettere le restrizioni di accesso. Se si dispone già di un livello di sicurezza / autorizzazione, questo dovrebbe essere abbastanza facile da aggiungere. In caso contrario, provare a trovare il punto all'interno dell'applicazione più vicina alla query del database e aggiungere i controlli lì. Qui è dove avere un livello di accesso ai dati di qualche tipo renderà davvero la vita molto più facile.
Se sei stato abbastanza intelligente da utilizzare le stored procedure, allora è ancora più semplice modificare le query. La tua applicazione sta già trattando i proc memorizzati come un'interfaccia astratta, quindi l'aggiunta dei controlli di autorizzazione sarà trasparente per l'applicazione.
Un'altra opzione è creare viste basate sui client. Diventa un po 'più complicato farlo funzionare, ma potresti avere una tabella delle autorizzazioni simile che indica a quali viste un utente o un gruppo è autorizzato ad accedere. In fase di runtime, o forse attraverso una sorta di configurazione che controlli, alle query viene detto a quali visualizzazioni è consentito andare contro.
Quando scrivi dati nel database, devi assicurarti che la proprietà sia registrata insieme ai dati. È una sfida programmatica simile a quella delle query, ma ti incoraggio ad assegnare la proprietà a un ID di gruppo del cliente anziché a un singolo utente. L'eccezione potrebbe essere se hai un utente generico che rappresenta il business del cliente.
Se non si dispone di costrutti nello schema del database per organizzare i dati all'interno di oggetti che possono essere assegnati a un client, prendere in considerazione la creazione di tale. Invece di avere un numero di miliardi di righe di dati a cui ClientA può accedere, ci sono un migliaio di righe di dati appartenenti a ObjectA che ClientA capita di possedere. Estrarre la proprietà di un oggetto può semplificare alcune delle query di accesso quando si dispone di un numero complesso di oggetti all'interno del sistema.
Sorprendentemente, è tutto per il passaggio a un ambiente multi-tenant. Ovviamente, il dolore è nei dettagli. Raccomando di avere test di unità e integrazione per verificare che i meccanismi di sicurezza funzionino come previsto.
Riguardo a OOP & modularità - i tuoi pensieri generali sono sulla buona strada. Ma tieni presente che puoi usare i principi OO in un linguaggio strutturato come C. Ci vuole più governo per mantenere quello stile di codice, ma puoi ottenere alcuni dei vantaggi della modularità che stai cercando.
Se non disponi già di un livello di accesso ai dati, ora è il momento di prendere in considerazione la possibilità di installarne uno. Avere un DAL contribuirà a promuovere l'integrazione di tale logica all'interno di un'area e il disaccoppiamento dell'accesso al DB dal resto dell'applicazione. L'implementazione di questi principi renderà più facili le modifiche future.
Esistono altri approcci alla multi-tenancy come avere uno schema DB completo per client all'interno di un singolo DBMS. Avere più schemi ignora alcune delle modifiche di autorizzazione / proprietà che dovresti fare. Ma il lato negativo è che questo approccio può richiedere un server DBMS molto più grande.
Un'altra opzione è che puoi avere un DBMS completo per client per separare i dati. Ancora una volta, si ignorano alcune delle modifiche alla sicurezza, ma è necessario mantenere più server. L'integrità referenziale tra gli schemi diventa un problema con questa opzione.
Tuttavia, il contesto della tua domanda implicava che stavi cercando un multi-tenant con un DB condiviso, quindi non ho seguito questi approcci.