For the sake of argument:
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.
asked May 07, 2015 at 10:38 PM Mike.Riley ♦♦ 61
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.
answered Feb 12, 2016 at 12:01 PM huy 1
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.
answered Mar 10, 2016 at 06:32 AM jeffgibson 0