[SQL Server] - Meglio una sola tabella o più tabelle

[Igor Baldacci]

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

[comas17]

Mah, così di primo acchito, non mi piace molto..

SQL Server può gestire tranquillamente tabelle con centinaia di migliaia o milioni di record; peraltro, la tua "situazione in cui ci sono migliaia di UtentiRegistrati che a loro volta hanno centinaia di Clienti iscirtti" è basata su un'ipotesi realistica o è solo un "esercizio matematico" ? Magari ti ritrovi con solamente 400 registrati ed ognuno dei quali ha 30 clienti...

Pensa, ad esempio, che dopo aver creato 763 tabelle (relative ai clienti di 763 utenti registrati) tu veda la necessità di avere qualche informazione aggiuntiva (aggiungendo quindi un ulteriore campo)
Devi andate a modificarti tutte le tabelle invece di una sola...

Immagina di dover fare un po' di reportistica (o query in genere)...
Ti ritrovi a dover puntare a tabelle tutte con nomi diversi (ok, saranno del tipo tab_001, tab_002, tab_003, etc, ma sono comunque tutti oggetti diversi)

[luca200]

Originariamente inviato da Igor Baldacci
Ci sarebbero controindicazioni?

Sì, è un'idea totalmente senza senso

[mosquito70]

E' un'idea senza alcun senso, quella di creare n-tabelle, una per ogni cliente.

Per la gestione della cancellazione dei dati, potresti sempre optare per un partizionamento, ma chiaramente non 1 partizione per ogni cliente (!), ma un range sui codici degli stessi. Ma anche in questo caso non so che vantaggi avresti. Lo stesso dicasi per il partizionamento dei dati collegati a cliente.
Ipotizza anche l'uso di VIEW pensate ad hoc per l'estrazione dei dati.

Comunque, una tabella per ogni cliente e' assolutamente da evitare.

[Igor Baldacci]

ok grazie mi avete convinto!