Re: Nearest Common Ancestor Report (XDb1's $1000 Challenge)

Don't know why I'm wasting my time on this imbecile fraudster, but anyway...

neo55592_at_hotmail.com (Neo) wrote in message news:<4b45d3ad.0406081253.8deef80_at_posting.google.com>...
> > > XDb1 normalizes the second two by making references to the first one.
> > > There is only one brown in XDb1's db.
> > > Using RM#1 or #2, brown is stored three separate times [in 2 tables].
> >
> > That is not normalisation, it is using surrogate keys or pointers.
>
> In the most general sense, normalization is the process of removing
> redundancy. If you need to hear this from an authority in order to
> accept this common sense idea, see C.J. Date's "An Intro to Database
> Systems", 6th Ed, Chapter 10, Further Normalization I: 1NF, 2NF, 3NF,
> BCNF, pg 280 where he begins with "what is wrong with this design:
> redundancy", "redundancy leads to several problems", "so perhaps a
> good design principle is 'one fact in one place' (ie. avoid
> redundancy). The subject of further normalization is essentially just
> a formalization of simple ideas like this". In the summary of the same
> chapter, he restates "normalization ... the purpose of such reduction
> is to avoid redundancy".

The word "brown" is not a fact. The statements "my name is Brown", "my dog is brown" and "John's car is brown" are 3 distinct facts. Do you seriously believe that Date or Codd would support your warped definition?

> > You must be storing SOMETHING 3 times to indicate that "brown" is used
> > 3 times. Whether it is the word "brown" or the surrogate ID 1429476
> > or a physical memory address or whatever, you still have the SAME
> > level of "redundancy" in your model.
>
> The use of underlying, data-independent links/refs (ie ID 1429476) to
> the one and only original data within the db is not considered
> redundant in the context of dbs.

Nor is storing the word "brown" by any sane person.

> > Now stop this nonsense and PAY UP!
>
> Please show how RM Sol#1 or #2 can store the data without redundancy.

"brown", "brown" and "brown" will do just fine. No redundancy there.

> Also, please show how RM Sol#1 or #2 can store the earlier mentioned
> three thing hierarchy containing an unnamed person and a person with
> mulitple names.

So a person (or any "thing") can have 0, 1 or many names? In that case we would need tables something like:

create table thing (thing_id integer primary key); create table thing_name (thing_id references thing, thing_name varchar2(100),
  primary key (thing_id, thing_name));

Not a problem. Now pay Hugo. Received on Wed Jun 09 2004 - 10:57:39 CEST