Re: The MySQL/PHP pair

"Dawn M. Wolthuis" <dwolt_at_tincat-group.comREMOVE> wrote:

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

     Then, you define your terms, and run with it.

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

    Well, Date has made some adjustments to clarify it. You would think that he was overwriting everything about 1NF from the way you go on about it. It is not a surprise (to me) that theories can be refined.

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

^^^^^^^^^^^^^^^^^^^
     Please remember those key words.

>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

     That you compliment me is irrelevant to whether I agree with your ideas.

     The issue of kookdom w.r.t. to 1NF is not something that come to me in a flash. I have become increasingly uncomfortable about your stridentness against 1NF, particularly since you do not back it up with more than scraps. I came to the conclusion about kookness about two months ago, but have held it in abeyance. It is, thus, not a casually-reached conclusion.

>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

           ^^^^^^^^^^^^^
     So you have an opinion.  Big deal.  Most of us do.  Backing up

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

     You are overly eager to consign it to the void.

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

     That point has been made that MVL may work very well in a stable implementation where the necessity of relating data more than one way is unnecessary or not very much so.

     My experience is that it is easy to come up with a situation where the data has to be looked at in a different way.

>2. RDBMS's do not properly implement the relational theory, but once we
>have a "real" RDBMS, then all will be well

     The first part is definitely true. The second part is hopeful, but a religious issue.

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

     From what I have read, MySQL has serious deficiencies.

     Maybe, we will. This is another religious item.

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

     Irrelevant at the logical level.

     At the implementation level, of course, but that is true of any software.

>So, are you writing me off as a kook or not? smiles. --dawn

     w.r.t. to 1NF, until such time as you put in an acceptable showing for a proof, yes, albeit reluctantly.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:

     I have preferences.
     You have biases.
     He/She has prejudices.