Table-Driven Design

Last Updated: January 5, 2015

Definition - What does Table-Driven Design mean?

Table-driven design is an approach to software development engineering that is aimed at simplifying and generalizing applications by separating the program control variables and parameters (rules) from the code and placing those in separate external tables. The main objective is to decouple the program control data from the application logic and to put emphasis on modularity to ease change management.

[Free White Paper] Demystifying data science: How organizations can benefit from artificial intelligence and advanced analytics

Techopedia explains Table-Driven Design

Table-driven design makes use of tables as they are concise and represent relationships well graphically, making it easy for the designers/programmers to understand immediately what they are doing. Using tables, they can transform information of one kind into another kind. For example, the names of two cities can be converted to the distance between them or their population or land area difference, depending on the information available on other tables or other parts of the same table. In the same vein, a collection of conditions in a program can be directly transformed into a series of actions or procedures by using a decision table.

A table is any data structure that consists of rows and columns, with the columns usually fixed in number, whereas rows are variable. Arrays, lists, stacks, indexes, control blocks, files, graphs and charts are also forms of tables, but just because a program uses them it does not neccesarily mean that it uses a table-driven design.

Table-driven design is nothing new; its basic principles were originally developed and implemented as early as the 1950s, but did not really gain ground then. This was mainly due to the fact that main memory was very expensive at that time and disk access speeds were already viewed as adequate compared to normal systems, while programmers were not yet well versed in writing efficient access methods, and there were no ready-made ones yet. Therefore, it was not really favorable for table-driven software design to flourish.

Tables have the following benefits:

They provide concise and orderly specifications of the business goal or challenge during the analysis phase.

They can be implemented directly and easily from the specifications, which also provide a very close link between theory and application. This is during the design and development phase.

Tables can be shared to allow for single and centralized changes for quick turnarounds with minimal risk to the existing code during the maintenance and enhancement phase.