Penso che l'approccio più sano sarebbe avere un database per ciascun utente. La maggior parte dei database è progettata per gestire la sicurezza molto meglio se un utente ha il potere sul proprio database e nient'altro (si vorrà utilizzare uno speciale utente di back-end per poter creare il database, creare l'utente e assegnare permessi per quell'utente di accedere a quel database - qualsiasi altra cosa è un rischio per la sicurezza ).
Ogni utente avrà il proprio database con le autorizzazioni per modificare solo quel database. Questo rende tutto molto più semplice. Non è più necessario trasformare tutto virtuale poiché la maggior parte dei problemi sul database si può semplicemente inoltrare all'utente. È necessario un database master che tenga traccia degli utenti, delle autorizzazioni e dei relativi database. Molti database offrono meta informazioni, ma non lo consiglierei di usarlo, almeno non per gli utenti, dal momento che qualsiasi informazione aggiuntiva dovresti gestirti comunque, e quindi probabilmente stai facendo quello che dovresti fare alla fine comunque.
Una cosa che non dovresti salvare in master a questo punto è una tabella di tabelle - Questo, dovresti davvero lasciarlo al database da gestire. Se hai bisogno di un elenco di tabelle, puoi interrogare la meta per queste informazioni.
A questo punto, l'unica vera preoccupazione sono i conflitti tra i nomi dei database. Per risolvere questo, potresti fare una delle tante cose:
- Fornisci il nome tu stesso. Sarà un brutto nome e questa non è la decisione più popolare per gli utenti, ma è la più semplice da fare.
- Lascia che forniscano il nome e esegui una sorta di mappatura del nome da virtuale a reale che crei tu stesso. Questo è abbastanza semplice, con l'eccezione che è necessario analizzare le query e sostituire il nome da soli (non lo consiglio!)
- Aggiungi il nome utente sul lato sinistro del nome del database che selezionano quindi non c'è alcuna possibilità di nomi in conflitto (usa una sorta di divisore di caratteri che non può essere usato nel nome del database per non doversi preoccupare degli utenti "me" con database "atloaf" e utente "meat" con database "pagnotta" che crea lo stesso nome).
Questa è ovviamente una soluzione pesante per il database in quanto ci si basa principalmente sul motore del database per portare la logica dietro ciò che è possibile e impossibile realizzare, quindi consiglio vivamente di sapere come mantenere il database (la sicurezza è un maggiore priorità qui) che alla fine scegli.
Con il passare del tempo, è possibile sovrascrivere determinate funzionalità se si richiedono determinati comportamenti che non è possibile ottenere normalmente con un database, ma questo approccio è sicuramente vantaggioso in quanto si ha già un sacco di logica completata per voi con poco o nessun tweaking.