Re: The MySQL/PHP pair

"Laconic2" <laconic2_at_comcast.net> wrote in message news:CLKdnfG3h-v6mBbcRVn-1w_at_comcast.com...
>
> "Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote in message
> news:cmem4f$g32$1_at_news.netins.net...
>
> > I actually didn't say that he never made such a claim (although I didn't
> > know if he had) but that he originally was well aware that normalization
> was
> > based on pragmatics and not on some mathematical principle.
>
> I guess I've been misunderstanding your position.
>
> Are you saying that normalization, as such, is not mathematical?
>
> There are certainly other places in math where the term "normal form" is
> used.

I'm saying that as far as relations go, there is nothing about relations that says that using them as a model for data means that you must eliminate repeating groups (the old version of 1NF). There is no mathematical reason that a relation must be in 1NF (by the old def).

>
> > My claim is that there is nothing about modeling data logically as
> relations
> > that requires 1NF (as previously defined).
>
> Agreed. But that's not the same thing as saying that it's not a good
> modeling principle.

Correct. I don't think it is a good modeling principle, although it can be a useful technique when modeling, but I have not proven that it is a bad principle. In trying to figure out why current RDBMSs and related software development environments have been so bulky, brittle, and costly compared to other environments, I'm taking baby steps pulling off what I see as areas I see where there have been misconceptions. 1NF is one little one. How/where constraints are handled by the DBMS is another one. Both of these are embedded pretty deeply embedded in our thinking about databases. So, while baby steps, they could help us shake some of the foundations enough to be able to move forward without some of the same ball and chains we have been carrying.

> It's that point where your point of view and mine differ.
>
> > I have no hidden agenda unless it is also hiding from me. I have an
> > interest in advancing the discipline of software development and ongoing
> > maintenance.
>
> My interest, on the other hand, is advancing the discipline of data
> management.

The reason I do not state it that way is that I fear that could be partitioning it in a way that continues to hold us back. I, too, have an interest in data management (either that or I'm a very bored housewife, eh?) but my interest is in data whether it is stored or not. At the logical level, I would like to work with data throughout the entire system consistently. So, whether the data are stored on a disk or in memory, I want to query it, maintain it, verify it, etc consistently.

> > One of the obstables might be RDBMS's as currently
> > implemented.
>
> I'd suggest that most of your points would apply equally to any DBMS. You
> yourself have said that Pick is NOT a DBMS.

Point taken.

> How about the current IBM products you keep mentioning. Are they DBMSes?

They claim to be. They definitely provide added value on top of simply persisting data to a file system (such things as triggers, for example), so I suspect they have the right to claim that. They also likely claim to be RDBMS's because you can use SQL if you choose to do so.

>
> > My experience and intuition RATHER THAN ANY proven theory or
> > emperical data suggests that we need to do something decidedly different
> > with data storage for at least a good number of software
implementations.
> > Maybe one of these days it will all be clear how to either prove
something
> > mathematically or gather the right emperical data to bring this
together,
> > but until then, I'm still on a search.
>
> I would suggest that you widen the search to include those people who DID
> get good "bang for the buck" out of the RDBMS implementations that you
> think are part of the problem.

I would really like to have some way of getting some emperical data rather than the anecdotes I have read from people using a variety of databases. PostgreSQL users can be very passionate about the bang for the buck (open source) they get from their environment. So, I loaded it and checked it out and I suspect it is a good bang for the buck. I've looked at Berkeley-DB and others as well, but have not done anything that would constitute a scientific experiment.

 I simply don't know how any data could be collected that would tell any of us anything we didn't already believe to be true. If we want to test "big bang for the buck" in data management, both for initial software development and for ongoing support over time, how could we do that? Are there any such studies out there?

--dawn Received on Fri Nov 05 2004 - 15:01:08 CET