Re: The MySQL/PHP pair

Dawn M. Wolthuis wrote:

>> Also, it would be much easier to
>> do this if those specs were data instead of code.

>> Also, adding automation to the specs instead of just constraints would
>> greatly enhance their value.

Two things. On the code=data thing I'm going to have to work up a good rant on why they are not, but trying to do it in a quick post on my break is a bad idea, that one will have to wait.

For automation, think this way. Start with the database definition, or specification, if you will. The database definition must be complete, it must completely describe every table and column, and entirely in scalar data.

The universe of column definitions are then divided into two kinds, USER-SUPPLIED and AUTOMATED. User supplied columns come in to the server from some outside source, either a keyboard or an EDI routine or a one-time load or whatever, and are subject to constraints. AUTOMATED columns have their values generated by the system based on user-supplied columns and other automated columns. The only constraint upon automated columns is that an INSERT or UPDATE statement cannot directly write their values.

You can do amazing things when you expand the worldview to include Automation. The basic example is Extended_price = price * qty, but through the miracle of composition you can pretty much do anything.

DBAs generally have a huge mistrust of Automated columns because they view the world through a fish-eye lense called "normalization", often forgetting that the purpose of normalization is to ensure correctness. When you apply the single constraint that users cannot update automated columns, you serve the motivation for correctness and get a big win.

What the DBAs generally miss is the difference between a specification and an implementation. I can define the database column in the order details table Extended_price = price * qty without deciding how to implement it, but getting the definition right should still drive the implementation on all tiers.

Programmers on the other hand tend to see the world entirely in terms of automation, and so ignore normalization or think that it is some silly chore as in "normalize till it hurts, denormalize until it works." That motto should be "normalize till its right, denormalize to take flight." if you completely normalize your USER-ENTERED data, you can then denormalize only with AUTOMATED data. Then you have one sweet and powerful database.

-- 
Kenneth Downs
Use first initial plus last name at last name plus literal "fam.net" to
email me