SQL prestazioni tabella VS tabelle

[andrestu]

dovendo implementare un database che potrebbe arrivare a contenere molti dati sono indeciso tra due soluzioni diverse:

- creare una tabella dove all'interno inserirò tutti i dati
- dividere i dati per più tabelle

Quello che mi chiedo è che se il numero di dati aumenta notevolmente quale delle due soluzioni da prestazioni migliori e quale occupa meno spazio su disco.

Premetto che i dati verranno prelevati e inviati da un sito Aspnet e il DB Sql è alloggiato sullo stesso dominio di hosting del sito.
I dati da inserire saranno suddivisi x ogni utente, nel senso che ogni utente del sito avrà i suoi dati.
Quindi x esempio se ci saranno 1000 utenti potrò avere una tabella con 1000 righe ed ognuna assocciata ad un utente oppure 1000 tabelle ognuna x utente.

Quindi se x esempio se io facessi un select x un utente sarebbe più prestante prelevare i dati dalla tabella contentente 1000 righe o nell'altro modo?
e cioè quando faccio un select da aspnet ad una tabella di 1000 righe e ci inserisco la clausola "WHERE user = @user" (quindi in questo caso mi preleverebbe solo la riga dell'utente coinvolto) il select verrà fatto su server SQL e quindi non avrò tutto il transito delle 1000 righe da SQL ad IIS o viceversa?

bisogna considerare il caso in cui più utenti fanno richieste e modifiche al DB contemporeanemente...

[RoBYCoNTe]

secondo me sbagliatissimo, ancora una volta non capisco perchè vi ostinate ad intraprendere soluzioni le cui specifiche sono cosi complesse e delle volte sbagliate. Esiste la tabella utente che ha N utenti, non esiste una tabella per ogni utente, poi bisogna analizzare il contesto in cui questa applicazione verrà utilizzata, in generale ci sono molte variabili che influiscono sulla progettazione di una web-application. Ti posso già dire che se la quantità di dati che andrai a caricare si può quantificare nell'ordine delle migliaia SQL Server fà una passeggiata.

Ciò di cui ti dovresti preoccupare e realizzare una web-application che sia in grado di servire questa mole di dati ad un numero "N" massimo di persone che possono, secondo te, essere connesse nello stesso momento. Qui è dura!

[andrestu]

per quanto riguarda il discorso "tabella utente" i dati relativi ad ogni utente non potranno essere contenuti in una riga sola ma potrebbero volerci anche 10/20 righe ad utente, quindi una tabella potrebbe arrivare anche a contenere 10/20.000 righe, e se mi dici che Sql non ha problemi a gestire anche 10000 righe in una tabella allora preferisco anchio l'implementazione di una tabella x più utenti.

Il punto che vorrei chiarire riguardo la quantità di dati che vengono spostati, è che se in caso di "select" filtrato x esempio da un sqldatasource di aspnet le 10000 righe vengono passate da Sql Server al server Aspnet già filtrate oppure ad Aspnet arrivano tutte le 10000 righe e poi successivamente avviene il "WHERE user = @user"(facendo un esempio)?
penso che se sia valida la seconda (non credo) allora conviene la suddivisione in più tabelle.

Invece per quanto riguarda la connessione simultanea di più utenti così si può fare senza mettere mano direttamente su sql server in qualità di amministratore del server?
cioè devi solo progettare l'applicazione in modo che le richieste simultanee arrivate ad un tot vengano automaticamente interrotte o cosaltro si può fare daltro canto? questo fattore dipende dalla progettazione dell'host che ti ospita io in qulità di sviluppatore della web application ho un pò le "mani legate" o sbaglio?

[RoBYCoNTe]

Se una tabella utente può contenere 10-20 righe per ogni utente significa che si può progettarne una versione migliore che possa contenere riferimenti e chiavi esterne per decrivere altre proprietà dell'utente che si possono ripetere (altrimenti il db non è progettato bene), per quanto riguarda le query, qui mi sembra che manchino le conoscenze di base.
1. Da aspnet, tramite la tua applicazione viene inviata una query al server sql.
2. Il server analizza ed esegue la query (quindi applica anche i filtri impostati).
3. Il server invia il risultato alla tua applicazione che deve analizzarlo, non invia tutti i record presenti nel db, ma solo quelli che corrispondono ai criteri di ricerca applicati (se un db funzionasse alla tua maniera oggi non funzionerebbero bene parecchie cose o ci sarebbe una congestione della rete mondiale).

Cmq per quanto riguarda la progettazione dell'applicazione dovresti porre attenzione su proprietà come il Connection Poolig,l'MSDN parla molto attentamente di questo argomento, oltre dovresti progettare pagine leggere e veloci, ma qui penso che solo l'esperienza e la pratica potranno aiutarti (il tutto sommato a delle buone/issime conoscenze del contesto e degli strumenti con cui stai lavorando).

[andrestu]

si infatti x quel che riguarda l'esempio del select in effetti pensandoci bene ho detto un pò una cazzata rispetto all'ipotesi del passaggio totale dei dati.
diciamo che volevo avere la certezza che funzionasse alla maniera da te spiegata.

comunque grazie x i suggerimenti, consulterò l'MSDN.