Re: The MySQL/PHP pair

"Gene Wirchenko" <genew_at_mail.ocis.net> wrote in message news:ed1io01krh95t861k6b7bbh6pmnvhp7nd2_at_4ax.com...
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote:
>
> [snip]
>
> >What type of proof would you accept -- I could lay out the original def
of
>
> Well, you harp about a mathematical proof for the necessity of
> 1NF, so how you supply a mathematical proof?

If I am to prove the lack of mathematical rigor in requiring what was once known as 1NF, then I would use the papers that originally defined the concept (which is what I did) and show that the arguement in those papers was not mathematical (which I did, although not recently). However, if someone else is using some other definitions or papers, then that would not convince them.

> >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.
>
> Of course it would be easier if he did your work for you, but you
> made the claim that 1NF is faulty. YOU prove it.

I did. Which part needs to be revisited? The original statements from Codd's 1970 paper indicates that a relation may include another relation and the subsequent papers, including the 1974 paper IIRC state that the reason for normalizing (using 1NF) is to simplify the operations. That is not a mathematical rationale.

What is lacking from this from your perspective. I'm willing to fill in more details, but do not know what you need yet to be convinced.

> You really have a bee in your bonnet about 1NF. You say that you
> know x or that you are unsure about another x, but regardless, you
> still push that view on 1NF. After due consideration, I have come to
> think of you as a kook w.r.t. 1NF. That is not a compliment.

It is but the first bee in my bonnet. It is the most obviously flawed aspect of relational databases as implemented to date from my perspective.

And here I just complimented you in a previous post of mine, but if you must think me a kook, that is your issue and not mine. The reason for continuing to press on it is that we, as a profession, must get past it to make progress, in my opinion. We are not going to get there until software developers, DBAs, professors, textbooks, and database products (ODBC, for example) move forward. This is no small step, but one I'm trying to pitch in on to help us move forward. We need to get the word out there that 1NF as we knew is dead and we can now move forward from there.

> [snip]
>
> >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.
>
> This is an example about the bee in the bonnet.

By the way, Gene - is it only women who get these bees in their bonnets? I've never, to my knowledge, worn one.

I'll admit that I'm still on a search for why this very old-fashioned development environment (multivalue) which now has a new-fashioned look to it (for example, TigerLogic from Raining Data using it as their XML engine) gives such a bigger bang for the buck for a company than the use of an RDBMS from what I've seen.

Possibilities:
1. What I've seen and experienced is an exception and it is really the caes that companies are better off with RDBMS implementations 2. RDBMS's do not properly implement the relational theory, but once we have a "real" RDBMS, then all will be well 3. There are some significant issues with RDBMS's that older and newer environments are addressing and we just might see a "linux of the database world" show up on the scene to put a dent in the Oracle, DB2, and SQL Server trio to an even greater extent than MySQL has already.

> >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.
>
> This is another.
>
> [snip]
>
> >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
>
> Or is it simplification? At the logical level, those are not
> needed.
>
> >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.
>
> So put them in the database, and have them enforced by the DBMS.

I don't care what the software is called -- if it is "the DBMS" that populates a drop-down box with the right values, so be it. We would want to be careful about what is proprietary with a single vendor supporting it, however.

So, are you writing me off as a kook or not? smiles. --dawn Received on Wed Nov 03 2004 - 18:35:26 CET