Loan Amortization Schedule for SQL Server

  • >> The point being that, at it's core, this is a math problem. Storing pre-calculated values makes about as much sense as storing multiplication tables. <<

    I hate to tell you this, but if you look inside a calculator, you will find lookup tables for the values because it's faster and easier to do it that way than it is to recompute key values over and over. In fact, few decades ago, one of the mail-order companies was offering a deeply discounted scientific calculator whose lookup table had an error for the value zero.

    The other consideration is that in the commercial world, very often you don't have to deal with a general problem. The company will have a few hundred or a few thousand packages defined in their offerings. In the old days, printing them out and looking them up manually could kill a lot of trees :-). Today, huge amounts of data can be kept in electronic storage and access to almost instantly. It is certainly worth considering. I once did a lookup table for packaging mail-order barbecue that had only ~5000 arrangements ever shipped. Whenever they ran into a new configuration, the packing slip was pulled from the processing line and marked for manual handling.

    Please post DDL and follow ANSI/ISO standards when asking for help. 

  • jcelko212 32090 wrote:

    >> The point being that, at it's core, this is a math problem. Storing pre-calculated values makes about as much sense as storing multiplication tables. <<

    I hate to tell you this, but if you look inside a calculator, you will find lookup tables for the values because it's faster and easier to do it that way than it is to recompute key values over and over. In fact, few decades ago, one of the mail-order companies was offering a deeply discounted scientific calculator whose lookup table had an error for the value zero.

    The other consideration is that in the commercial world, very often you don't have to deal with a general problem. The company will have a few hundred or a few thousand packages defined in their offerings. In the old days, printing them out and looking them up manually could kill a lot of trees :-). Today, huge amounts of data can be kept in electronic storage and access to almost instantly. It is certainly worth considering. I once did a lookup table for packaging mail-order barbecue that had only ~5000 arrangements ever shipped. Whenever they ran into a new configuration, the packing slip was pulled from the processing line and marked for manual handling.

    That's all well and good. I acknowledge that it is entirely possible that SQL Server is referencing hidden system tables with it's POWER and/or LOG functions. Assuming that is the case (I actually have no idea), it still wouldn't justify storing additional copies in user tables.

  • I have a question and I am still somewhat new to SQL but can you pass multiple loans to this to get complete amortization schedules and if so how would you go about doing that?

Viewing 3 posts - 16 through 17 (of 17 total)

You must be logged in to reply to this topic. Login to reply