Re: The MySQL/PHP pair

Dawn M. Wolthuis wrote:

> "Kenneth Downs" <firstinit.lastname_at_lastnameplusfam.net> wrote in message
> news:069bmc.sb3.ln_at_192.168.10.210...

>> Dawn M. Wolthuis wrote:
>>
>> > OK, I didn't understand what you were referring to as "adding

>> > It sounds like you are referring to virtual and/or materialized
>> > user-defined
>> > data, virtual fields, derived data, UDFs, stored procedures, etc. 
>> > These are
>> > all automated by way of  "code" specified in attributes as metadata,
>> > right? So your "USER-SUPPLIED" columns are supplied with the metadata
>> > having no "code" other than name, size, type, desc, or whatever, where
>> > your "AUTOMATED" have additional "metadata" to derive the value from
>> > whereever, rather than requiring that the data be stored directly
>> > (maybe?).
>> >
>>
>> We are pretty much on the same page on all points except one.  The
>> specification of automated columns must not contain code, they must be
>> scalar.  The two working points to define scalar (or atomic) in this
>> context are:

no, the specification is not code. It is not code-in-disguise, it is not declarative statements, it is not something that will be reduced to scalars. It is not an ordered list, an unordered list, a bag, or an array.

It is a structured collection of indivisible atomic scalar values. Data is not code.

>

>> 1.  Must not require evaluation according to the rules of any programming
>> language.
>>
>> 2.  Must not require parsing by the engine built to use it.
>>
>> So if you have some automatic view builder working with a data
>> dictionary, the formula for Extended_Price cannot be the expression
>> "price * qty", it must be the scalar values "MULT","PRICE","QTY" with the
>> assumption that

>> columns are in the same table.  In the same vein, an aggregate for an

>> total might be "SUM","ORDER_LINES","LINE_FINAL_AMT".

It is not a language because it has no grammar or syntax. It is a structured collection of atomic values. It is not semi-structured, it is hard-structured. My own structure happens to be in normalized relations, but other models could probably be used.

Now, my crack about Assembly Language is the *only* way to argue me out of this. Be we are not coding Assembler, and at the lofty levels of 4GL-land where we live we confound code with data at our peril.

I might ask this question, don't you want to manipulate the meta-data as easily as you manipulate the customer's data in the system? Do you really honestly believe you can do that with COBOL or SQL or Java? Really? If you can, then why not store customer information as a series of declarative statements like "Customer XYZ would like 3 tulip bulbs by Spring" and "John Smith submitted payment of $25.00 on January 25th." Why? Because it makes no sense to manipulate facts that are adorned with all of that human grammar, we replace that grammer with data structures that give pigeonholes to the data values, and we fill those pigeon holes with INSERT and UPDATE statements and we examine them with SELECT statements. You cannot issue a SELECT statement against English text.

One thing I do *not* have to do is write a PARSER. I do not have to parse Cobol, other people wrote those already. I do not have to parse SQL, Oracle and Microsoft do that. I do not have to parse Java or C#, others have written those tools. I can concentrate entirely upon building things out of the data and not waste a single second getting at logic that has been trapped in application code.

Finally, consider this: I must have that specification somewhere somehow. Either it will be "trapped" in a word document that will be irrelevant almost as it comes off the printer (been there, seen that), or in spreadsheets, or in (horror or horrors, true story) in the inboxes of the participants. Why not put it in the form it belongs in in the first place, in data? Then build the backend out of it, generate as much code as you can out of it, and have a 2nd team write a tester in some completely independent system that will verify the system you built conforms to the spec you've established? The cost of doing that with *any* language, declarative or otherwise, is much higher than just doing it out of data.

You cannot know that a specification is correct until you have reduced it to the smallest simple propositions, which operate on scalars, and you cannot test it until you have that set of propositions to compare to the finished product.

whew, have to catch my breath here....

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