Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Mathematical Operation Expand / Collapse
Author
Message
Posted Saturday, March 15, 2014 7:26 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, November 5, 2014 3:46 PM
Points: 135, Visits: 102
Hi,

I need to write a stored proc that takes a set of input parameters and then performs mathematical operation referencing several other lookup tables and interim calculation results.

The set of input comes from a table - so I need to process all rows in the input table.

Will a while loop \ cursor be recommended for this type of operation or not at all?

The other option then will be to have several temp tables - as output from joining the lookup tables?

Please advise!

Thanks,
Post #1551533
Posted Sunday, March 16, 2014 12:47 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 7:45 AM
Points: 7,860, Visits: 9,606
A lot depends on whether the mathematical operations needed can be performed by queries using aggregates, joins the apply operator, and so on. On what you've told us, there's nothing that says it can't be done with a single SQL statement and equally nothing that says it can be done with multiple operations and loops. As a general rule, it's a good idea to try to aoid using explicity loops (and of course explicit cursors) but there are a few cases where the general rule doesn't actually fit (usually where someone has the schema design screwed up, but some real cases too).

Tom
Post #1551589
Posted Sunday, March 16, 2014 1:27 PM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Wednesday, November 5, 2014 3:46 PM
Points: 135, Visits: 102
Hi Tom,

As I mentioned there are several tables to join and one calculation feeds another table \ calculation.

So IMO (if possible) doing all that in one SQL will make it a ugly looking SQL.

Breaking it down in multiple lines is ideal from the readability \ maintenance of the calculation.

Cheers,

Bikram
Post #1551591
Posted Monday, March 17, 2014 5:23 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 11:53 AM
Points: 7,154, Visits: 15,646
Pretty sure Tom got the high level description. The problem is - it's so generic, we have no way to provide you with advice on how to implement. Hopefully there is a way to provide SOME detail, enough to point us to that general idea, but keep enough back so you can still protect whatever idea you are trying to build.

----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
Post #1551962
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse