Re: The MySQL/PHP pair

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Fri, 5 Nov 2004 08:10:25 -0600
Message-ID: <cmg1kn$cpm$1_at_news.netins.net>


"Paul" <paul_at_test.com> wrote in message news:418b4557$0$4012$ed2619ec_at_ptn-nntp-reader01.plus.net...
> Dawn M. Wolthuis wrote:
> > My claim is that there is nothing about modeling data logically as
relations
> > that requires 1NF (as previously defined).
>
> If you start with first-order propositions when building your model then
> I think 1NF is required.

I know I have some reading to do re 2nd order logic so that I really understand just where we move from 1st to 2nd order logic being required and just where 2nd order logic is problematic when querying data.

What is the problem if I want to persist the proposition:

Person
Bob Smith has e-mail addresses of bob_at_aol.com and bobsmith_at_msn.com

It seems to me that there are advantages to modeling this predicate in this way rather than modeling it with the statements

Email
The Person with ID 12345 has an e-mail address of bob_at_aol.com The Person with ID 12345 has an e-mail address of bobsmith_at_msn.com

Person
The Person with ID 12345 is Bob Smith.

Conceptually a single statement is clearer. If the database has some reason of spitting our one predicate into three prior to storing it and before retrieving it, so be it, but logically why not handle it with the single statement?

> If you start out with something else - higher-order propositions maybe -
> then you aren't required to have 1NF. Whether this is a good idea or not
> is a different question.
>
> I guess all business data is basically a set of propositions, so your
> basic choice is whether to go with first-order logic or higher-order
> logic. I guess you could use some structure other than relations to
> organise those propositions but I'm not sure what exactly.

Relations, particularly those that are functions, work well from my perspective, but, again, I don't know where the higher order logic becomes a problem. Thanks. --dawn

> Paul.
Received on Fri Nov 05 2004 - 15:10:25 CET

Original text of this message