Re: The fable of DEMETRIUS, CONSTRAINTICUS, and AUTOMATICUS

From: Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net>
Date: Sun, 24 Oct 2004 10:44:46 -0400
Message-ID: <v4fglc.jkh.ln@mercury.downsfam.net>

Marshall Spight wrote:

>> I would contend that it is never appropriate to consider SQL code to be
>> data, it simply is not.

>
> I respect your viewpoint however I disagree.
>
> SQL code is most certainly data; it is at the very least a string,
> which I can manipulate in any of various ways and get back
> another string which might itself be valid SQL which I could
> then execute.
>
> The fact that you said "never" makes your position untenable.
> If you say "mostly" I will agree with you, but "never" is
> way too strong.
>
>

>> Code is data when you get down to certain levels, yes, like bytecode, and
>> food is paper when you get down to carbon and nitrogen.  But again I
>> contend that when implementing database systems or meta-data systems
>> there is only madness in confounding code and data.

>
> Hmmm. So perhaps you meant "never when implementing database systems
> or meta-data systems."
>

My bad. I would say never if you are the user of a DBMS, meaning anybody who is not the vendor/implementor. The vendor's role is to parse the SQL and turn it into an execution plan. And yes, as you say, they can do some very useful things along the way, as is done in the PostgreSQL rules engine.

But I hold by the "never" when you are the user of the system, but as a judgement call based on experience. It should be possible to demonstrate that:

SQL(scalars) < Scalars(SQL)

Which is to say the cost of generating SQL out of scalars is less than the job of generating scalars out of SQL. That's one I can't prove. But here is something easier to demonstrate.

Consider a reporting engine, with 2 cases of how to build it. In case 1 you are given scalars, such as lists of columns, lists of group by's etc. You are told to generate SQL queries based on the scalars. In case 2 you are given pre-built queries, told to parse them, possibly modify them based on flags or scalars, and rebuild some SQL. The steps are:

Case 1: Scalars -> SQL
Case 2: SQL -> Scalars -> SQL

There is an extra step in Case 2, and it is not a trivial one.

My contention is that if you are treating SQL as data, meaning parsing it to obtain table-like information, then consider storing that information as data in the first place, and put your effort into a SQL generator, since you have to do that anyway.

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

Received on Sun Oct 24 2004 - 09:44:46 CDT