What was that old article advocating table-oriented programming?
Asked by
MellowCedar47
I'm trying to track down an article I read roughly 20 years ago. Its main argument was that many behaviors developers usually implement as functions or procedures could instead be represented as database tables and interpreted by the application. The claimed benefit was easier maintenance: when requirements changed, you could add, remove, or update rows instead of rebuilding and redeploying the application. The article used several surprising examples of logic that could be modeled this way. I vaguely remember it being plain ASCII text and possibly hosted on an older technology site. Does this sound familiar, or are there similar essays that make the same argument?
Answers
This idea is often described today as configuration-driven development, data-driven programming, or a rules engine. Modern examples include systems where business rules, workflows, pricing, or eligibility decisions live in tables and are interpreted by generic code.
Reply to this answer
The closest match I know is the essay commonly referred to as “Table-Oriented Programming,” associated with TopMind. It discusses representing behavior and rules as data rather than hard-coding everything. The archived versions may be what you remember, although the exact copy or hosting location could be different.
Reply to this answer
There are also narrower, well-established uses for this pattern. Lookup and calibration tables are common in measurement and embedded systems, where a device can use precomputed values or behavior tables while keeping the firmware relatively small. That is more constrained than moving an entire application’s logic into a database, but it follows the same general principle.
Reply to this answer
A major practical drawback is that database changes do not automatically provide the development tools people expect from source code. You still need history, review, rollback, testing, environment promotion, and clear ownership. Without those safeguards, a flexible rules table can become harder to understand than ordinary application code.
Reply to this answer
The approach can work well when the rules are genuinely data-like and change frequently. It becomes much less attractive once the rules need complicated conditions, branching, state, or relationships. At that point, the table format starts turning into a programming language and you have to build conditionals, jumps, stacks, validation, testing, and versioning around it.
Reply to this answer
Add your answer
Answers are reviewed before publication.
MellowCedar47: That distinction was one of the things I remember liking about the original article. It wasn’t claiming that every line of code should become a database row; it focused on recognizing situations where the flexibility was actually worthwhile.