Salve a tutti,
mi accingo a realizzare una specie di portale dove gli utenti registrati hanno una propria area "Clienti" dove regsitrare e gestire i proprio utenti.
Quindi avrei, sintetizzando, una tabella "UtentiRegistrati" e una tabella "Clienti" legate tra loro con una chiave secondo la più classica configurazione di un DB relazionale:
[UtentiRegistrati]
ID_UtenteRegistrato (PK)
NomeUtente
...
[Clienti]
ID_Cliente
ID_UtenteRegistrato (FK)
NomeCliente
....
Fin qui lo standard.
Quello che mi chiedo e vi chiedo è se, invece di usare una struttura con 2 tabelle di questo tipo, non convenga usare una tabella per gli "UtentiRegistrati" e poi tante tabelle "Clienti" create a runtime per ogni utente registrato. Cioè:
[UtentiRegistrati]
ID_UtenteRegistrato (PK)
NomeUtente
...
(questa è la stessa)
[Cliente1]
ID_Cliente
NomeCliente
(tabella Clienti dell'UtenteRegistrato con ID = 1)
[Cliente2]
ID_Cliente
NomeCliente
(tabella Clienti dell'UtenteRegistrato con ID = 2)
[ClienteN]
ID_Cliente
NomeCliente
(tabella Clienti dell'UtenteRegistrato con ID = N)
In questo modo invece di avere un unico TABELLONE "Clienti" avrei tante tabelle "ClienteX". Avrei quindi una struttura più ordinata e facile da gestire. In caso di cancellazione di un Cliente eliminerei direttamente la tabella, ecc.
Secondo voi è inutile un approccio di questo tipo, oppure potrebbe essere migliore? Io immagino una situazione in cui ci sono migliaia di UtentiRegistrati che a loro volta hanno centinaia di Clienti iscirtti... la tabella "Clienti" sarebbe davvero enorme. Senza contare poi tutte le ulteriori tabelle per la gestione di altri contenuti, come ad esempio un'eventuale tabella "Fotografie" che ciscun cliente può inserire sul sito, e così via.
Sto dubbio mi attanaglia, anche perchè, di contro, avrei centinaia di tabelle che il DB deve gestire... voi che dite? Ci sarebbero controindicazioni?
Grazie a tutti