Re: basic question
- From: Phil <foo@xxxxxxx>
- Date: Mon, 14 Aug 2006 22:23:23 +0100
On Mon, 14 Aug 2006 21:31:16 +0200, "Cor Ligthert [MVP]"
<notmyfirstname@xxxxxxxxx> wrote:
"CSharpguy" <CSharpguy@xxxxxxxxxxxxxxxxxxxxxxxxx> schreef in bericht
news:0DA4358F-D9AF-4DA9-B2C1-2861C9E4BCEA@xxxxxxxxxxxxxxxx
I'm not sure if this is the correct forum or not, but I have a basic
question. Currently we have are doing calculations via stored procedures
and
then returning the results back to the client in either a web page or a
Sounds good - minimal data transferred.
winForm style application. There are times that the stored procedure takes
20
minutes or 3 hours to run. Now, our database person says that all the
That's very variable - do you have a locking problem? Or is the
variability to be expected from the input data?
calculations needs to be removed from SQL and put in either the web
applications code or the winForms code (based on what is calling it) the
db
person also states that SQL is not intended to do any kind of math
(calculations)
Nonsense. It's phenomenally good for surprisingly complicated
mathematics. You may want to consider getting another "SQL person" :-)
and they should all be done in the application. I think the
calcs should be done on the db and its going to take 20 mins to 3 hours
for
I tend to agree (on the db, not sure about the time...)
these things to run no matter where the calcs are happening.
So, my question is: Where should the math(calculations) take place? In the
Stored Procedure or the application side?
Hmmm, it's difficult to say. I assume that one of the reasons these
procs take so long is because they have to process a large amount of
data, in which case *I* would like to have them run on the SQL server
as it means less data being transmitted on the network. SQL server is
also usually able to make very good decisions about accessing the data
in the best way because it maintains the indexes and statistics about
the distribution of values in the columns.
You definitely shouldn't move it out to the web/WinForms code, that
would be dumb, when instead you can move it out into a business object
layer (basically a class library) that is callable from either web or
WinForms. Some people advocate doing this, and it can be useful, but
only if you can find another box (often called an "application
server") to run it on; and bear in mind that you would have to
transfer the data from the SQL box to this application server box.
One of the advantages of moving the logic out of the database is that
people usually find it easier to build flexible business rules into
the logic, though personally I am a data-centric person and find no
problem with doing it all in procs...
Don't jump yet.
Frankly, I would be tempted to start by really understanding what your
procs are doing. Is this a CPU bound or an IO bound problem? Have you
determined where the time is being spent in the procs? I never met a
stored proc I couldn't speed up somehow. Ask your SQL person to do a
query plan analysis and check the indexing - that should keep him
quiet for a bit :-) Assuming this is MS SQL, you may want to take this
to microsoft.public.sqlserver.programming but you need to be more
specific about your problem first.
Good luck! Wish I could do it for you, I love speeding things like
this up, my spider-sense is telling you should be able to get it going
10 times faster :-)
--
Phil
.
- Follow-Ups:
- Re: basic question
- From: Pritcham
- Re: basic question
- References:
- Re: basic question
- From: Cor Ligthert [MVP]
- Re: basic question
- Prev by Date: Re: Why Serialization
- Next by Date: Re: ComboBox Behavior
- Previous by thread: Re: basic question
- Next by thread: Re: basic question
- Index(es):
Relevant Pages
|
Loading