Re: The MySQL/PHP pair

Kenneth Downs <firstinit.lastname_at_lastnameplusfam.net> wrote in message news:<bpsbmc.226.ln_at_192.168.10.210>...
> 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
> automation".
> >> > 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:
> >
> > The specification IS code, but the value is scalar, right?
>
> 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
> all
> >> columns are in the same table. In the same vein, an aggregate for an
> order
> >> total might be "SUM","ORDER_LINES","LINE_FINAL_AMT".
> >
> > Isn't this just a specified "language" so that there is some interpreter
> > that determines that it needs to multiply the price times the quantity? I
> > think I'm still missing something. I don't see a great deal of difference
> > between the words "multiply" "price" and "quantity" being in an xml
> > documet that is interpreted by some software to mean that it should
> > multiply the price times the quantity, or encoding this same thing in
> > COBOL, for example. Either way it is code with an interpreter or compiler
> > so that the
> > multiplication is executed. Where is your scalar values of "MULT" stored
> > and what software is interpreting it? --dawn
>
> 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....

Right on! I'm convinced.

• Dan