Ciao,ho un sito sviluppato in asp.net e con un db sqlServer. Su una pagina ho problemi di prestazioni, dato che devo caricare parecchi dati. Uno dei problemi è l'apertura del db.Per almeno una parte del codice potrei usare metodi alternativi, ma mi chiedevo quale fosse il più efficiente. In pratica devo decidere se aprire una tabella di sqlServer, un file excel o un semplice ASCII.Che cosa è più veloce?
Grazie
di *quanti* dati stiamo parlando?
Diciamo che ho attualmente una tabella con 4 campi numerici e fino ad ora siamo sulle 70.000 righe. Pensavo di dividerla a blocchi perché le dimensioni potrebbero crescere sensibilmente. Diciamo che non vorrei arrivare sopra le 100.000, ma non è detto.
cosa intendi con "caricare" i dati? dacci qualche info in più, grazie
Questa è la pagina:
http://www.ricetteedesideri.it/RED/R...caRicette.aspx
Per fare la ricerca devo andare a cercare in diverse tabelle nel mio db, dato che è molto complesso. Nel caso pratico, se seleziono zucchini devo aprire la tabella degli "ingredienti per ricetta" e andare a ricavare tutte le ricette che contengono zucchini, per poi mettere questi dati in un'altra query che è poi quella che mi da la visualizzazione.
Potrei ricavare la lista delle ricette anche da altra fonte (tipo file che riscrivo periodicamente) se questo mi portasse un vantaggio in termine di tempi.
credo che tu ti stia perdendo in un bicchier d'acqua... se metti tutto in un db te la cavi con qualche select ben mirata. in questo caso - usi M$SQL Server, se ho ben capito - 70.000/100.000 righe sono niente
In realtà non è tanto così. Le 100.000 righe sono già considerando le tabelle separate.
Poi avevo già usato una struttura del tipo SELECT * FROM WHERE RicettaID IN (SELECT DISTINCT RicettaID FROM ...)
Ti assicuro che anche con meno record mi mandava in time out.
Adesso ho qualcosa del tipo
SELECT * FROM WHERE RicettaID = 1 or RicettaID = 2, ma per popolare il WHERE devo fare una chiamata al DB. Con questo numero di record funziona, ma se si passasse, come penso, a 10 volte tanto non so se la cosa potrebbe ancora funzionare.
Senza contare che ho 3 casi di ingrediente da selezionare e altrettanti di ingredienti da eliminare. Posso ridurre le opzioni alla peggio, ma prima di farlo volevo essere sicura che non ci fossero soluzioni alternative. Da qui l'idea di splittare la tabella originale
ripeto, 100.000 record sono un niente. ovvio, devi costruire le query in maniera adeguata. se una singola query è troppo pesante - come nel caso della SELECT ... WHERE IN (SELECT ...) - puoi preparare delle stored procedures che saranno senz'altro molto più veloci
Mi chiarisci un'altro dubbio che avevo. Non uso le store procedures perché non ho mai avuto il tempo di mettermi a studiarle con calma, ma da quello che mi dici potrebbero aiutarmi in questo caso.
Ne approfitto ancora per chiederti se sai dove posso trovare qualche manuale che mi aiuti.
cerca "mssql stored procedures tutorial" su googlebuon lavoro
Permessi di invio
Rispondi quotando