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.

Didn't you mean "Data are not code"? smiles.

OK, I read what you wrote and I buy your distinction. You have data in fixed columns which avoids the parsing necessary with a language.

> >
> >> 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.

OK, I'm tracking.

> 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.

There is some logical level at which I see them as two sides of the same coin. Users "code" rules into columsn in a database, for example. Whether the design calls for them to write "a = b" as a value for an attribute or "a" as the value for one attribute, "EQ" for a second, and "b" for a third, all has the same result, just a different interpreter.

> 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.

There is still logic "trapped" (stored) somewhere in some format that needs to be interpreted by sonmething.

> 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?

I agree -- I put data element names, sizes, and types all in data. Metadata IS data, afterall (and "code" is metadata, in my opinion). I think of code as data in that it can be stored in a database just like any other document. It then serves as input to a compiler, for example. At the logical level, we are working with data as input, a function on that data, and data as output. That's it -- data and functions on data. When we store data, we typically store it with a key, thereby making our stored data into functions as well (the key being input to the function which returns the value of a row of data). So, in general, we can think of data as functions. Also, functions can be used as input to other functions, thereby being input data (or similarly, output).

Therefore, data are functions and functions are data and we are just dealing with one thing -- call this data or functions; data or code -- just two sides of the same coin.

> 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.

OK.

> 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....

well, it is appreciated. I think I'm just looking at the logical level differently -- perhaps more abstractly in this case -- to arrive at the statement that data and code are two sides of the same coin. I do see your point, however. Cheers! --dawn

>
> --
> Kenneth Downs
> Use first initial plus last name at last name plus literal "fam.net" to
> email me
Received on Wed Nov 03 2004 - 20:08:07 CST