A properly designed SQL database with the correct indexes should handle a
query like you describe in a matter of a few seconds.
"Properly" designed means the right balance between normalized and
not-normalized, for the querying purposes. Highly normalized databases
require many joins, which slows the query. Highly de-normalized means fewer
joins, which is better for querying, but also means data is duplicated across
the tables, and must be maintained via triggers, etc.
The correct indexes means, are there "covering" indexes for the query? (A
covering index is one in which the index itself contains the data which the
query will need, so that it is unnecessary for SQL to leave the index and go
to the data leaf to get the data required by the query.)
Finally, using the Query Analyzer, you should be able to evaluate how SQL
will process the query, and determine where your query is slowest, and why.
It was tough to tell anything from the diagram - even expanded it was too
small to see the details.
(I myself have a long VFP background. IMHO SQL is to the Foxpro data engine
what a Porsch is to VW bug.)
[quoted text, click to view] "MajorTom" wrote:
> Hello Everybody
>
> I have the question about the SQL Server Performance and design
> considerations.
>
> I am developing code that is going to deal with a lot of records (specific
> detail in the attachment). I am writing code right now that is working fine
> with a few records. My concern is to know how the performance is going to
> respond when the database get the full load (that I don't have now).
>
> Just for complete my scenario, I came from FoxPro database and have about 3
> years with C# and visual studio and this is my first full SQL Server
> application.
>
> The attachment (jpg file) is the query that most concern to me for the
> performance problem, if some one can see it and contact me for further
> explanations.
>
> it was to big for attachment, the image is here and use the full size botton
> for get the detail information
>
http://privadas.fotopic.net/p14387002.html >
> Specific questions about the query:
>
> The result for the parameter (@id_articulo) is going to be a few thousand
> when the database has millions of records, what time normally take a query
> like this with all the best approach that you can recommend?
>
> The query has to be saved as a Store procedure? All I read said for the best
> performance it's recommended the store procedure, is that right?
>
> The recommendation for index, and clustered index?
>
> We may need the new 64 b Windows Server 2003?
>
> Any recommendations and best approach for the query
>
> Thanks everybody and don't forget to have a nice day!
>
> MajorTom
>
> PD: Sorry for my bad English
>
>
>
Hello Everybody
I have the question about the SQL Server Performance and design
considerations.
I am developing code that is going to deal with a lot of records (specific
detail in the attachment). I am writing code right now that is working fine
with a few records. My concern is to know how the performance is going to
respond when the database get the full load (that I don't have now).
Just for complete my scenario, I came from FoxPro database and have about 3
years with C# and visual studio and this is my first full SQL Server
application.
The attachment (jpg file) is the query that most concern to me for the
performance problem, if some one can see it and contact me for further
explanations.
it was to big for attachment, the image is here and use the full size botton
for get the detail information
http://privadas.fotopic.net/p14387002.html Specific questions about the query:
The result for the parameter (@id_articulo) is going to be a few thousand
when the database has millions of records, what time normally take a query
like this with all the best approach that you can recommend?
The query has to be saved as a Store procedure? All I read said for the best
performance it's recommended the store procedure, is that right?
The recommendation for index, and clustered index?
We may need the new 64 b Windows Server 2003?
Any recommendations and best approach for the query
Thanks everybody and don't forget to have a nice day!
MajorTom
PD: Sorry for my bad English
