What is Table-Driven and Data-Driven Programming?

Data/Table-Driven programming is the technique of factoring repetitious programming constructs into data and a transformation pattern. This new data is often referred to by purists as meta-data when used in this fashion.

Data Driven and Table-Driven Programming Examples

/**Naive approach **/
function returntax($usstate, $price){
	$result = 0;
	switch (strtoupper($usstate)){
		case 'MA':
			$result = 0.05*$price;
			break;
		case 'NJ':
			$result = 0.07*$price;
			break;
		case ....//ad nauseum
	}
	return $result;
}

If you look at this closely, you would observe the pattern of a*b where a is some function of state and b is the price. If you were to take the data-driven approach, then you would write the function as

function returntax($usstate, $price){
	$result = 0;
	$aryStateTax = array('MA'=>0.05, 'NJ'=>0.07, ...); 
	if (array_key_exists(strtoupper($usstate), $aryStateTax)) {
		$result =  $aryStateTax[strtoupper($usstate)]*$price;
	}
	return $result;	
}

function returntax($usstate, $price){
	global $db;
	$result = 0;
	$rs = $db->Execute('SELECT tax FROM lustates WHERE state =' 
						. $db->qstr(strtoupper($usstate)));
	if (!$rs->EOF) {
		$result =  $rs->fields('tax')*$price;
	}
	$rs->Close();
	return $result;	
}

The above is a fairly trivial example of Table/Data Driven programming. In the next couple of sections, I shall demonstrate more powerful constructs of the general approach.

Using Data to Generate SQL

One neat trick is that of using data to generate code. For example say you wanted to write a cross-tab query and you didn't want to hand-code it as you often have to in most databases.

Cross Tab Query

--Naive repetitive painful way
	SELECT proj_id, SUM(CASE WHEN proj_fund = 'Fund A' THEN amt ELSE NULL END) 
		As [totFund A], 
		SUM(CASE WHEN proj_fund = 'Fund B' THEN amt ELSE NULL END) 
			As [totFund B],
	...ad nauseum, SUM(amt) As totalcost 
	FROM projectfunding 
	GROUP BY proj_id

--Using SQL to generate SQL - Table Driven
DECLARE @sql varchar(3000)
SELECT @sql = 'SELECT proj_id, ' 
SELECT @sql = @sql + 
	' SUM(CASE WHEN proj_fund = ''' + fu_name + ''' THEN amt ELSE NULL END) 
			As [tot' + fu_name + '], '
FROM lufunds where fund_category = 'Federal' ORDER BY fu_name

SELECT @sql = @sql + ', SUM(amt) As totalcost FROM projectfunding GROUP BY proj_id'
EXEC(@sql)

The above approach has several benefits over the first. One it makes our code a bit shorter thus possibly easier to read and our query dynamically changes with the records in lufunds. We can sort our columns with ease without having to touch the code and the naming of the columns is guaranteed to be consistent with the convention we choose. This means a general user can change the definition of the query without touching the code.

Here is a similar example using a PostgreSQL custom SUM aggregate for text and generate_series functions - that generates sql and ASP.NET markup for a monthly crosstab report.

On the other hand, it is a bit harder to read for a novice programmer and is more prone to run-time breakage should something silly be put in the fund lookup table.

A Rudimentary Code Generator

Another class of problems where data-driven programming comes in handy is in generation of business rule code, formulas and just general code-generation. For scripted languages such as PHP which has eval interpreter syntax `` (for PHP) or Javascript where you often generate this code on the fly, this approach comes in immensely handy because it allows you to codify the logic in a generic pseudo-code way and then apply certain transformation patterns to translate your logic into the programming environments needed. For example you may want your logic to work on 3 tiers - the client-side, the server-side middle-tier, and your core database tier.

• On the client-side you need something like Javascript for validation or to create highly portable pricing calculators
• On the server side (should your javascript validation fail) or should you need to make this logic available to other apps you need something like PHP, VB, Python etc,
• on the database side you need SQL for your triggers or to update batch sets of data.

On top of that, what if the rules are constantly changing and you have a financial analyst or engineer writing these rules who is intimately versed in financial and/or engineering models but not in general programming? How do you make your code dynamic such that it changes with the rules and such that your rules are understandable and editable by a financial analyst or other Non-Programmer?

How do you write the rules and have it translate to all areas where it is needed without having to tweak each side when you need the logic to change?

One approach is to write the core of your logic as data (pseudo-logic that can not stand on its own) that is stored and written in such a fashion that it is easy for the rule maker or analyst to understand, can be passed thru a black box function or set of functions that will translate it into executable code for the environments you need it in, and can be self-documenting.

Creating such a format and creating the black-box functions is tricky for an all-purpose situation, but if your set of rules uses a very limited vocabulary (a mini domain language) - it is much more doable. A high level view of your system would look something like this.

• Data A + VBTransformPattern -> VB Code with logical meaning C
• Data A + JSTransformPattern -> Javascript Code with logical meaning C
• Data A + SQLTransformPattern -> SQL with logical meaning C
• Data A + EnglishTransformPattern -> Self-documenting report to CFO with logical meaning C

Where Data A is the logic written in your mini domain language that fits in the place holders in your transformation patterns.

Data, Logic and Function - What's the difference?

It is interesting to note that some languages do not make much of a distinction between data and function and allow passing of pointers to functions just as easily as passing other data. In fact if you look at the underlying architecture of many languages say C++, VB, and several other OO languages, these are founded on what are called VTABLEs even though this subtlety is hidden from its regular use. VTABLES are nothing more than tables that basically hold pointers to functions. Languages like Smalltalk allow one to pass anonymous blocks of code in data structures and apply them to other data structures. So we see that data can change data by some sort of activation function and control logic itself can be stored and changed.

We see that some of the most powerful constructs in programming treat functions,logic, and pseudo-logic as data. So then if logic and functions are data are they a special class of data - meta-data? Perhaps it is the wrong question to ask. The more important questions to answer I think deal with what we are trying to optimize for our particular situation - speed, flexibility, brevity and clarity. The items we care about most will dictate how we partition our logic into the various buckets. Highly productive programmers are keenly aware of their desired results and trade-offs and are experts at finding just the right balance of rigid code and data to arrive at that end. This gives rise to a wide spectrum of uses such as simple lookup driven flow to more advanced uses like self-replicating machines that morph based on data environment changes.