Re: The MySQL/PHP pair

"Laconic2" <laconic2_at_comcast.net> wrote in message news:m8mdnekuD_WFwxTcRVn-3w_at_comcast.com...
>
> "Dan" <guntermann_at_verizon.com> wrote in message
> news:Kg0id.6107$wP1.5011_at_trnddc09...
>>
>> "Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message
>> news:cm93fd$g11$1_at_news.netins.net...
>> > "erk" <eric.kaun_at_pnc.com> wrote in message
>> > news:1099431388.630616.174500_at_f14g2000cwb.googlegroups.com...
>>
>>
>> [snip]
>> >
>> > It makes sense to bring it up since I have yet to PROVE all of my
>> > concerns.
>> > I have proven, I think, that 1NF as currently implemented by most
> software
>> > developers (the old version of 1NF) has no mathematical basis.
>>
>> What is this proof, pray tell. I've asked for a demonstration already
> where
>> attributes of a relation are anything less than an elements in the
>> mathematical or logical sense when operated upon by relational operators.
>>
>
> I think the following has been demonstrated beyond reasonable debate:
>
> That not all relations (or collections of relations) are in what Codd
> called
> "normal form" in the 1970 paper.
> That some relations (or collections of relations) are in "normal form".
> That Codd never claimed a mathematical basis for reuiring "normal form"
> in
> the relational data model.
>
> That what Codd called "first normal form" in the followup papers on data
> normalization (1972, 1973) is the same thing as nroaml form in the 1970
> paper.
>
> That, in the only formal definition Codd ever gave of frist normal form
> (called 1NF nowadays), atomicity of attribute values is an essential part
> of the definition.
>
> That the atomicity requirement of 1NF is not part of the formal definition
> of the term "relation" in mathematics.
>
> That Date revised the definition of 1NF so as to remove the atomicity
> requirement. (don't know the year).
> That this revision was based on the pragmatics of IT, not the mathematics
> of relations, since 1NF was not a requirement based on mathematics.
>
> I say all this as one who is NOT convinced of Dawn's opinion that 1NF (a
> la
> Codd) was an obstacle to greater progress through the 1080s and 1990s. Or
> of her opinion that database constraints are counterproductive or
> submarginal.
> These remain to be shown.
>
> But the fundamental question of whether mathematical relations hinge on
> 1NF
> a la Codd has been dealt with, as far as I can see.

I'm glad there is closure in your mind. Unfortunately, I think this is a fundamental issue and I don't quite see it your way. Sorry, Laconic2. I should know better than argue with a guy who graduated from MIT (IIRC). Perhaps it is just a matter of interpretation. :-)

>
> My point is that we have an alternative to going around in circles,
> debating
> the same old issues with the same old arguments every time around.
>
I think the difference in opinions is this. I made an effort to use nested relations, nested sets, complex objects, etc. in terms of a theoretical model and in terms of what is available as part of SQL99 implementations now. I tried to formulate the questions, use complex values as keys, create and implement methods, enforce constraints, share common "encapsulated" data, etc. I've gone through the motions of trying to understand how predicate calculus, and by extension, relational calculus would manipulate such sub-elements.

It was counterproductive in that it was overly complex and severely lacking in expressiveness. Integrity couldn't be enforced to the same degree as a "flat" relational model (i.e. RI from sub-elements to 1st order elements couldn't be declared or enforced). Optimisation was constrained and even sub-optimal. Logical queries did not always produce consistent results. The list goes on and on. When I stated in earlier conversations that we hadn't even scratched the surface in terms of issues, I was speaking from experience.

For those of you who have actually gone through similar paces, I'd like to hear your stories. Perhaps they yielded more success. But, I'd rather not hear about intuitive guesses about what might work because the feeling is that it might be more productive and because *one* of Codd's paper didn't have the explicit presecription, "thou shall not use complex attribute values," especially from people that haven't at least tried to either design, or at least use, such a system. This is not a set of statements directed at you by the way Laconic2; rather, just musing out loud.

Regards,

Dan Received on Thu Nov 04 2004 - 08:44:36 CET