|
|
|||||||||
|
|||||||||
| |||||||||
|
|
|
| |||||||||
| View Poll Results: Help with Database Design - Ratebooks | |||
| 1111 | | 0 | 0% |
| 1111 | | 1 | 100.00% |
| Voters: 1. You may not vote on this poll | |||
![]() |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Rate Thread | Display Modes |
|
|
|
Get inside! Sample the range of functionality easily built with JMSL Library for Time Series Data Analysis, Heat Maps, Portfolio Optimization, Monte Carlo Simulation, Stock Price Charting and more. Download Now! |
|
#1
|
|||
|
|||
|
Database Design - Ratebooks
We are undertaking a project where we utilise a quotation system for Contract Hire, Hire Purchase etc.
In the past we have constructed 'ratebooks' or a table that pre calculates all possible results, ready to be called. Based on a number of variables but including Term of Contract & Mileage driven. We present the visitor with a list of items and the appropriate Monthly figure. This is very quick but it relies on the pre-built info. We are looking for possible alteratives for a more flexible approach. Any ideas? |
|
#2
|
|||
|
|||
|
I don't understand how this is a problem. Any modern DBMS can do on-the-fly calculations in a query. So, if you have a formula that you use to populate your static lookup table, just translate that into the SQL query. The output can look identical to the end user, (make the Rates table a VIEW, instead of a static table). Now you don't have to update your Rates table every time you change a parameter.
__________________
The real n-tier system: FreeBSD -> PostgreSQL -> [any_language] -> Apache -> Mozilla/XUL Amazon wishlist -- rycamor (at) gmail.com |
|
#3
|
|||
|
|||
|
On a side note, what's the poll for?
|
![]() |
| Viewing: Dev Shed Forums > Databases > Database Management > Database Design - Ratebooks |
| Thread Tools | Search this Thread |
| Display Modes | Rate This Thread |
|
|
|
|