Re: The MySQL/PHP pair

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

If you go back to the original Codd papers and look at the definitions of relation and normalization, you can see that, as Codd acknowledges, there is nothing in the mathematics that prohibits relations (or functions, bags, sets, ...) as elements of relations. The rationale for 1NF was to simplify the operations at least at the start of our work with data in relations. This was not a mathematical argument, but a pragmatic one. Relational theorists have now ditched 1NF (by redefining it as being a necessary property of a relation and not requiring atomic values in relations). So, neither relational theorists nor those who were already working with non-1NF data formats require data in what used to be 1NF form.

If this does not prove to you that there is no mathematical basis for the old 1NF, start where I did -- with the original definitions and papers -- and see if you can find such a basis for the old version of 1NF (I REALLY, REALLY WISH THEY HAD NOT CHANGED THE DEF DRASTICALLY, BUT HAD DITCHED IT ALTOGETHER AND USED NEW TERMS!). There is, nor has there ever been, any mathematical rationale for the old 1NF and Codd did not pretend that there was such (at least at the outset).

Those who still keep to it because it is simpler than other models are trying to simplify the wrong thing -- they are trying to simplify the machine rather than the work of the user..

> Since others
> > have already ditched it, or redefined it to the point where every
relation
> > is necessarily in 1NF, that is just a start.
>
> That is not a proof and it certainly doesn't convince me. Just because
> others have *implemented* variants that are non-1NF doesn't make it any
more
> of a viable theoretical model, despite the fact that most conversations
> address this piecemeal and sometimes in an ad hoc way. I would prefer to
> see it addressed as theoretical model as a whole than see it presented as
a
> series of iterative heuristics.

What type of proof would you accept -- I could lay out the original def of relation and of 1NF and the original arguement for 1NF and show that while the def of "relation" is mathematical, the rational for 1NF is not. I can point to the statements in the prior works of Date (BR -- before the redefinition) where he makes jumps that are not mathematical in the discussion of 1NF. But it would be easier if you would point me to the discourse that you think has mathematical rigor and I can show you where the mathematics stops and non-rigorous statements are included.

> Moreover, there are several practical issues that present themselves. We
> cast out a simple and consistent system of logic in the form of a query
> language over queryable elements without presenting a replacement or
> alternative.

Yes, there are practical issues and the issue of the query language is the one that holds the most water -- when do we move from 1st to 2nd order predicate logic, for example. I have not studied that at all, I'll admit, but I have something else to counter questions of practicality -- a system that works (it would fit the def of "legacy" given by Gene in another thread). There is a query language that goes by many different names (one for each implementation of the Nelson-Pick model) that successfully queries nested structures to a depth of n levels (n differs a bit but figure only 3) and that depth of nesting is just about what the human brain uses when forming statements (predicates), I'll claim. So, is it practical to leave the property formerly known as 1NF in the dust -- yes, it was practical before 1NF was born and it is practical today (dare I mention XML?)

> A simple model which is conducive to cheap, dynamic optimisation
algorithms
> using semantic or logical transformation might no longer be able to
leverage
> the same formal framework in terms of query decomposition and
normalization.

Once again, IBM has two such databases in their porfolio -- UniVerse & UniData and there are many others out there -- Revelation, jBASE, D3, mvBASE, UniVision, mvEnterprise, Reality.

> The definition of logical and physical independence will in all likelyhood
> have to be readdressed to clearly demonstrate and define at what level
> nesting occurs - the base logical level, at the physical level, at an
> external level, etc. This might seem self-evident to some, such as our
> esteemed Java programmers out there, but it isn't clear to me.

I care only about the logical, design level where a human being is interacting with the model.

As an aside, what language do you prefer be used for production software instead of Java?

> As I've said before, casting out 1NF and creating a sexier and extended
> model of database management might be of both value and be achievable.
But
> I am not certain as to what cost and to what extent complexity would be
> added. I think that if it were trivial, Codd wouldn't have constrained
> himself to 1NF. I am also of the opinion that Codd didn't rule out a more
> complex model for the same reason that I don't rule it out.

Yes, you are correct that there are costs. I would not be pitching this model if I had not seen with my own budget the difference between productivity for developers working with the old-pre-relational PICK model and the relational model. I still don't know all of the reasons why, so I'm walking around an RDBMS and the older (PICK) model to see what might account for this difference in productivity. One aspect of it, I think, is 1NF. Other aspects include where constraints are coded, the development environment, weak vs strong typing (and I don't want to get rid of strong typing but perhaps include it with the rest of the constraints so nothing new happens at the time of persistence).

I don't have the answer as to what would make software development more flexible, agile, productive,... but I am certain that the current RDBMS's need significant changes and I would rather start with earlier, more productive environments and evolve those to what we need than start with the rigid, bulky RDBMS's of today.

> There is a reason why analog communications and analog switches in
> communications networks are going by the wayside. They are sufficient and
> maybe even superior for the application they support, switching and
> conveying analog signals, but they aren't sufficiently general enough to
> scale for multiple applications, nor are they cost-efficient. Moreover,
> they are more complex and error-prone.
>
> In much the same way, I wonder how much benefit gets from adding this
> complexity to the data model. What is this fascination with binding a
data
> layer with an application layer, and with such close coupling?

It is the RDBMS that added complexity to the model -- requiring 1NF when people naturually think in lists and nested structures, for example. I'm looking to decouple the data constraints layer from the persistence mechanism. There is already coupling between a GUI, for example, and data validation -- I just don't want that to be different from the validation that then happens. Why have the GUI use one language and set of specs for data validation and the persistence mechanism another set of specs and code to do the same thing, again? That just means you have to keep these constraint specs & code in synch.

> [snip]
>
> - Dan

Let me know if/where what I've written is unsatisfactory and I'll see if I can state it better. Thanks. --dawn Received on Wed Nov 03 2004 - 15:43:03 CET