I have an application that does complex calculations for members. Each member can have multiple US states linked to their profile. Each state has got different calculations for each course a member completes.
As of now I have been performing the calculations in the DB (SQL Server 2008) and then sending data back to app layer where they can see their history and then download a certificate for each course.
I have a business logic layer but not a lot happens there. I know this has been asked a lot but where do you think I should perform these calculations: business layer or database? I am going back and forth!!
I would basically do anything in SQL Server that:
does a lot of summing, counting, averaging etc. of data and returns only a single value.
There’s really no point in transferring large volumes of data to the middle tier, just to sum up a column
does a lot of row / set-based manipulation; if you need to copy, insert, update lots of data, again, there’s really no point in dragging all that data to the middle tier and then sending it all back to the server – do it on the server right from the get go. Also: T-SQL is significantly faster in dealing with set-based operations (like shuffling data around) than anything in your middle tier could be
In brief: try to avoid sending large volumes of data to the client/middle-tier/business layer unless you absolutely have to (e.g. because you want to download a file stored in a database, or if you really need to have those 200 rows materialized into objects in your app to be displayed somewhere or operated on)
One feature that’s often overlooked are computed columns right in your database table – those are really good at e.g. summing up your order total plus tax and shipping into a grand total, or they are great to put together your first and last name into a display name. Those kinds of things really shouldn’t be handled only in the business logic layer – if you do those in the database directly, those “computed” values are also available to you when you inspect the database tables and look at the data in SQL Server Mgmt Studio …
I would put it into the middle tier / business logic layer
if it required extensive logic checking, string parsing, pattern matching and so forth; T-SQL sucks at those things
if it required things like calling a web service to get some data to validate your data against, or something like that
if it required more of a business logic operation (rather than strict “atomic” database operations)
But those are just “rough” guidelines – it’s always a design decision for each case, and I don’t believe in strict rules; your mileage may vary, from case to case – so pick the one approach that works best for any given task at hand.