Re: The fable of DEMETRIUS, CONSTRAINTICUS, and AUTOMATICUS
From: Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net>
Date: Mon, 25 Oct 2004 07:09:14 -0400
Message-ID: <rsmilc.e5o.ln_at_mercury.downsfam.net>
>
> Whether it IS code or not depends on the "Clinton Cliche": It depends on
> what the meaning of the word "IS" is.
>
>
> Whether there is a homomorphism between the SQL code and a certain body of
> metadata is quite another matter.
>
> Both you and Marshall have argued quite persuasively that SQL DDL is
> merely syntactic sugar for what can be expressed equally correctly and
> completely in meta data.
>
> I would be amazed if this turned out to be possible for SQL DDL, but not
> possible for SQL DML. I would also be amazed if this turned out to be
> possible for SQL DDL and DML, but not possible for procedural code in
> PL/SQL, and/or Java. After all, you can write Lisp s-expressions that
> will correctly and completely mimic anything that is computable in Java or
> PL/SQL.
>
Date: Mon, 25 Oct 2004 07:09:14 -0400
Message-ID: <rsmilc.e5o.ln_at_mercury.downsfam.net>
Laconic2 wrote:
>
> "Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message
> news:4ivelc.ivc.ln_at_mercury.downsfam.net...
>
>> I would contend that it is never appropriate to consider SQL code to be >> data, it simply is not.
>
> Whether it IS code or not depends on the "Clinton Cliche": It depends on
> what the meaning of the word "IS" is.
>
>
> Whether there is a homomorphism between the SQL code and a certain body of
> metadata is quite another matter.
>
> Both you and Marshall have argued quite persuasively that SQL DDL is
> merely syntactic sugar for what can be expressed equally correctly and
> completely in meta data.
>
> I would be amazed if this turned out to be possible for SQL DDL, but not
> possible for SQL DML. I would also be amazed if this turned out to be
> possible for SQL DDL and DML, but not possible for procedural code in
> PL/SQL, and/or Java. After all, you can write Lisp s-expressions that
> will correctly and completely mimic anything that is computable in Java or
> PL/SQL.
>
++good.
Sticking with relational data, all descriptions of relational data can be in relational data, and all operations upon relational data can be in relational data.
The basic example is showing that the simplest select is just a list of columns. Another list for group by, another for order by. The system assembles the join conditions from the DD. With the predicates you either go "Assembly" as I call it, or break the model by allowing expressions such as "date < {1/1/1990}".
Ken's opinion, FWIW is that this is not readily seen for the following three major reasons:
- Normalization failures. Anomalies in data require "special case" programming by the house wizard.
- Automation failures. The simple lack of data in the database requires complex operations to generate information on-the-fly. As a product or database "matures", it becomes more and more necessary to bring in the genius to get derivations out of the system.
- Feedback. Once the above two conditions take hold, the problems they bring on tend to be met with more of the same, reinforcing the position that "this is the only way to do it because this is the only thing we do."
-- Kenneth Downs Use first initial plus last name at last name plus literal "fam.net" to email meReceived on Mon Oct 25 2004 - 13:09:14 CEST