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?
5 Answers
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.
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.
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.
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.
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.
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.