Re: Generalised approach to storing address details

From: Neo <neo55592_at_hotmail.com>
Date: 11 Dec 2006 07:54:30 -0800
Message-ID: <1165852469.966066.190690_at_16g2000cwy.googlegroups.com>


> > Instead of asking the self-aggrandizing ignorant what he intends, which
> > plays into his hand, I suggest you let him know that google is his
> > friend. The design principle he seeks is POOD or the Principle of
> > Orthogonal Design.
>
> Because we know he won't read it of course.

Snippets from various prior posts related to POOD, none of which seem to invalidate the use of EAV as a solution to OP's requirements of complex/varied data structures some of which are unknown at design time:

The principle of orthogonal design requires that each of these ... tables have a unique predicate...

It seems an arbitrary rule to me, and it causes strange behaviours that they tried to fix with the now dropped Principle of Orthogonal Design...

BTW I don't agree with them in everything. For instance I am against the principle of orthogonal design, the view updating rules, transactions as a prescription of the RM, I am becoming very skeptical about the TransRelational Model, etc.

Alfredo Novoa: Darwen rejects the Principle of Orthogonal Design, and Date is reconsidering it, if it was not dropped yet. IMO The POD is a failed attempt to patch the strange behavior caused for not using the rules of logic in the translations.

Bob Badour: If you read the Loves/Hates example I suggested to Neo earlier and took the time to read up on _The Principle of Orthogonal Design_, you would see that Date and McGoveran discourage the use of the relation name (in this case L) to encode information. Instead of a binary relation with A and B, a better design would use a trinary relation along the lines of (Subject, Verb, Object). The postulate "John likes Mary" is simply the tuple: (Subject=John, Verb=likes, Object=Mary).

Neo: I was looking for a systematic way to represent arbitrary relationship(s) between any two arbitrary things in a database. Thus if thing1 is in tableX and thing2 in tableY, I would need to refer to them and the verb via Globally Unique IDs (guid). When traversing the table containing the subject, verb, and object, I would have difficulty in determining what tables the guids were related to. For my application, the _The Principle of Orthogonal Design_ did not provide an acceptable/practical method of representing arbitrary relationships between any two arbitrary things. Received on Mon Dec 11 2006 - 16:54:30 CET

Original text of this message