For the sake of argument:

  • Let's assume the application we are building is an amortization schedule.

  • Let's also assume that the database has a table called tblAmortizationPayments that stores the information about each monthly payment in a separate row.

  • Let's further assume that the database language can support the math calculations needed to perform the calculations.

If you were to build this amortization schedule for a 30 year mortgage, how would you decide between placing the code for performing these 360 calculations inside the database (I'm assuming this would be a stored procedure) or inside the application?

I'm more interested in your thought process for making this type of decision or any similar scenario that might come along.

more ▼
asked May 07, 2015 at 10:38 PM Mike.Riley ♦♦ 61 avatar image
(comments are locked)
10|600 characters needed characters left

I'm for putting the code in application. It would be convenient for mantainance and development in long term. It is convenient for deliver new version and hotfixed patch.

more ▼
answered Feb 12, 2016 at 12:01 PM huy 1 avatar image
(comments are locked)
10|600 characters needed characters left

I've found that a hybrid approach works really well. Sometimes you just have to put logic into the application. Maybe you want a snappy redraw. Something needs to be handled quickly.

However, sometimes, there are a lot of database activities that need to occur.

One example is this. In our transportation app. When a load sheet is entered, we need to have two entries generated for the origin and destination in our Org_and_det table. The moment the user hits the add button, it immediately enters the new row for the load sheet. The trigger fires the insert into the Org_and_det table. And I immediately pull those rows back into the main window. So all that data is instantly there.

However, I don't do a commit. Because if the user decides to cancel their entry, you have to be able to roll that entire transaction back.

That's the beauty of letting triggers and stored procedures handle your data sometimes. Plus sometimes it's just so easy on the database, it frees you up from having to write a bunch of logic on the client that hasn't been placed in the database yet.

Just throwing this out. Really found that there are a lot of reasons to use both locations.


Jeff Gibson
Intercept Solutions
Nashville, TN

more ▼
answered Mar 10, 2016 at 06:32 AM jeffgibson 0 avatar image
avatar image Mike.Riley ♦♦ Mar 30, 2016 at 01:57 AM

Thanks Jeff, it does help. I've always been afraid to use triggers. The main reason is I forget they are there. I was the lead programmer for a web development shop and we maintained upwards of over 300 database driven websites. I remember spending hours trying to troubleshoot an issue because I forget that triggers had been put in place. What is your secret to not forgetting about triggers?

(comments are locked)
10|600 characters needed characters left
Your answer

Up to 2 attachments (including images) can be used with a maximum of 524.3 kB each and 1.0 MB total.

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

"The unexamined life is not worth Living."
Socrates (469 – 399 BC)
This Question and Answer site is an outreach effort of the Association of Software Professionals. Without a doubt, the biggest benefit of joining the ASP is the member forums. Unfortunately, those forums are not available to the general public.

There are some extremely popular question and answer sites available such as StackOverflow & Programmers. However, those sites often close a lot of questions that deal with how to sell, market and operate a small independent software company.

Join the ASP today. Annual membership is only $100.
Jeff, This space is available.



asked: May 07, 2015 at 10:38 PM

Seen: 1070 times

Last Updated: Mar 30, 2016 at 01:57 AM