When I was a junior programmer I was encouraged to make applications "table-driven" as much as possible. What my project managers meant by this was to resist placing data values in program source code, and instead to have them in database tables. This made the applications more flexible. For instance, some source code might implement a business rule for calculating taxes on retail sales using a tax rate of three percent. If three percent was implemented directly in the source code, then if the rate changed to four percent, all the source code using three percent would have to be found. The programs concerned would have to be changed, and the new programs would have to be implemented in production. By contrast having the three percent in a database table that was accessed by the appropriate business rules meant that there was only one, known place where the data item needed to be changed. The flexibility of the table-driven approach supported ease of production maintenance, rather than anything else. However, it did mean that the defined components of a single business rule were found in more than one place.
All Information Management articles are archived after 7 days. REGISTER NOW for unlimited access to all recently archived articles, as well as thousands of searchable stories. Registered Members also gain access to:
- Full access to information-management.com including all searchable archived content
- Exclusive E-Newsletters delivering the latest headlines to your inbox
- Access to White Papers, Web Seminars, and Blog Discussions
- Discounts to upcoming conferences & events
- Uninterrupted access to all sponsored content, and MORE!