I forum Ricerca FAQ
Fai una domanda
Ultimo messaggio
lelex
lelex
l'1 agosto 2007 alle 16:40
41 messaggi dal 10 agosto 2001
Salve a tutti,
vediamo se mi date qualche dritta o mi dite che sto facendo giusto.
Allora dovrei ottimizzare un DB SQLServer lento e che non ho sviluppato io.
Sicuramente le query che hanno utilizzato si possono migliorare, ma prima di questo stavo pensando ad altro.
Prima di tutto hanno creato il DB specificando le chiavi nelle varie tabelle ma poi non hanno messo in relazione le varie tabelle tra di loro.
Prima idea mia per cominciare era appunto rivedere questa cosa e finalmente rendere sto povero db relazionale a tutti gli effetti.
Seconda cosetta che ho in mente è indicizzare le colonne utilizzate come filtri nelle varie query, almeno quelle utilizzate più di frequente.
Terzo mettere in opera qualche store procedure che invece hanno evitato.

Pensate che le prestazioni "velocistiche" possano migliorare con queste soluzioni?
E se si di quanto? molto, poco, ecc..

Se avetre altri consigli ovviamente sono tutto orecchi.

Grazie in anticipo.
Ciao
Lelex
RispondiQuoting
l.bianchi
l.bianchi
il 2 agosto 2007 alle 08:18
1.024 messaggi dal 19 dicembre 2003
Contributi | Blog
Pensate che le prestazioni "velocistiche" possano migliorare con queste soluzioni?
E se si di quanto? molto, poco, ecc..


Senza conoscere nulla del tuo db e soltanto sulla base di tue idee soltanto Houdini potrà darti una risposta al tuo quesito.
Rispondendo SOLO alle tue "idee" ti dico che introdurre dei vincoli fk serve a garantire l'integrità referenziale (indispensabile in un database) ma in nessun modo potrà migliorare le prestazioni del database.
Quanto alla creazione di indici qui invece hai la possibilità di migliorare le prestazioni attuali, ma a patto che fai una scelta ponderata introducendo SOLO indici effettivamente utili. Creare un indice inutile non è solo uno spreco di spazio ma si rivela deleterio per tutte le attività di modifica, inserimento e cancellazione di dati senza apportare alcun benefit in fase di lettura. Terzo, implementare delle stored procedure sicuramente contribuisce a migliorare le prestazioni ma non ti aspettare miracoli.

Un database si costruisce dalle fondamenta, ovvero dalla struttura dati ed eventuali errori che sono stati commessi in questa fase non puoi sanarli in nessun modo se non rivedendo la struttura stessa. Il secondo step è quello di costruire le query in maniera corretta. Se non parti da questi 2 qualunque altra attività nasce castrata...

Bye
Modificato da l.bianchi il 02 agosto 2007 08.21 -
RispondiQuoting
lelex
lelex
il 2 agosto 2007 alle 09:51
41 messaggi dal 10 agosto 2001
Grazie per la risposta.
Sono assolutamente d'accordo sul fatto che l'ottimizzazione si fa in fase di progettazione. Fatto sta che questo DB esiste già e quindi su quello devo lavorare .
Grazie ancora
Lelex
RispondiQuoting
maurodii
maurodii
il 2 agosto 2007 alle 11:20
294 messaggi dal 14 novembre 2001
Premetto che non sono un esperto: io ho trovato un discreto miglioramento delle prestazioni da pagine asp.net con connessioni a SQL Server usando il NameSpace System.Data.SqlClient anziché OleDB, mentre IDENTICHE prestazioni usando (oppure no) le Stored Procedure.

Ma queste Stored Procedure (a cui passo i parametri), che aiuteranno sicuramente a rendere più "pulito" e ordinato il codice delle pagine asp.net, non dovevano anche migliorare le prestazioni a livello di velocità?

Grazie x un eventuale risposta ;)
Modificato da maurodii il 02 agosto 2007 11.26 -
Campo Testaccio, c'hai tanta gloria...
RispondiQuoting
l.bianchi
l.bianchi
il 2 agosto 2007 alle 13:07
1.024 messaggi dal 19 dicembre 2003
Contributi | Blog
maurodii ha scritto:
Ma queste Stored Procedure (a cui passo i parametri), che aiuteranno sicuramente a rendere più "pulito" e ordinato il codice delle pagine asp.net, non dovevano anche migliorare le prestazioni a livello di velocità?


Le differenze prestazionali tra una stored procedure e query ad hoc è via via calata con il susseguirsi delle versioni di SQL Server dove è aumentata sempre più la possibilità di riutilizzo dei piani memorizzati in cache ANCHE per le query inviate come stringhe di testo.
Il vantaggio di usare le stored procedure è dato dall'assenza della necessità di fare il parsing del comando inviato (attività fatta in fase di creazione della stored procedure) e il fatto di creare un livello di astrazione della struttura dati sottostante (oltre ovviamente a semplificare il codice, centralizzarlo, ecc ecc ecc)

Bye
RispondiQuoting
lelex
lelex
il 2 agosto 2007 alle 18:59
41 messaggi dal 10 agosto 2001
Mi sovviene un'altra domanda...

L'utilizzo dei valori predefiniti può essere utile in un'ottica di ottimizzazione, faccio un esempio:
se devo ricercare tutti gli utenti che hanno il campo tipo='normale' ha una qualche differenza prestazionale farlo così:

select * from utenti where tipo='normale'

o

select * from utenti where tipo=dbo.miotipo

????

Grazie
Lelex
RispondiQuoting
l.bianchi
l.bianchi
il 3 agosto 2007 alle 08:43
1.024 messaggi dal 19 dicembre 2003
Contributi | Blog
lelex ha scritto:
se devo ricercare tutti gli utenti che hanno il campo tipo='normale' ha una qualche differenza prestazionale farlo così:

select * from utenti where tipo='normale'

o

select * from utenti where tipo=dbo.miotipo


In assenza di un indice sul campo tipo la query verrà risolta sempre e comunque attraverso un table scan quindi in questo caso è del tutto ininfluente se usi un datatype di sistema o uno tuo personalizzato (la differenza sta semmai in un eventuale incremento di spazio di uno udt rispetto ad un datatype di sistema). Se invece esiste un indice allora l'accesso avverrà anche (ma non è detto) attraverso un seek o uno scan dell'indice. Anche qui la discriminante è innanzitutto la selettività dell'indice (se non è sufficientemente selettivo l'accesso ai dati per mezzo dell'indice sarebbe antieconomico rispetto al table scan) ed anche le dimensioni dell'udt che si ripercuotono anche nel definire la soglia di selettività.
Attenzione anche che affinchè un udt sia indicizzabile devono essere verificati alcuni prerequisiti come indicato in questo link e in quelli in esso indicati

http://msdn2.microsoft.com/en-us/library/ms131082.aspx

Bye
RispondiQuoting
lelex
lelex
il 3 agosto 2007 alle 15:12
41 messaggi dal 10 agosto 2001
Grazie ancora
Lelex
RispondiQuoting

Torna al forum | Feed RSS

ASPItalia.com non è responsabile per il contenuto dei messaggi presenti su questo servizio, non avendo nessun controllo sui messaggi postati nei propri forum, che rappresentano l'espressione del pensiero degli autori.