Re: Something new for the New Year (2008).

From: TroyK <cs_troyk_at_juno.com>
Date: Thu, 3 Jan 2008 10:18:22 -0800 (PST)
Message-ID: <094cea18-8122-4a1f-b27b-008df0f3af70_at_61g2000hsx.googlegroups.com>


On Jan 1, 6:01 pm, JOG <j..._at_cs.nott.ac.uk> wrote:
> On Jan 1, 10:45 pm, Rob <rmpsf..._at_gmail.com> wrote:
>
> > If you have a chance, please take a look on my website at this page:
>
> >http://www.sfdbs.com/toplevel/fasttrack/fasttrack.shtml
>
> > You will see a completely new way to use foreign keys
> > to represent relationships in relational databases.
>
> > Working with this new representation has forever changed the way I
> > look
> > at and  think about relational databases.
>
> > Rob
>
> Well, I gave it a good effort but when I got to: "Compare this to
> PKFK: Where allowed, an orphan is represented by a NULL
> Child_Parent_fk foreign key value. Childless parents are always
> allowed and are represented implicitly by the absence of reference in
> Child_Parent_fk among all Child tuples" I was fighting the urge to
> jump ship.
>
> Tuples in databases represent facts stated in the real world (they are
> not entities or objects), and yet here you are adding link tables,
> pointers, agregate tables, orphans, etc. And yet I don't see anything
> added that a well designed schema wouldn't achieve. Imho, I hope you
> didn't spend too much on patents.

Seconded....

From the paper:
"There doesn't seem to be any commonly accepted name for the Figure 1 representation. "

Sure there is. It's called a subset requirement constraint.

Many more gems like the above where the author betrays his lack of understanding of the subject matter.

Good luck with the patent, anyway, I guess. I think I'm going to patent FK declarations -- according to your paper, they're much more ubiquitous, so I can better reap the benefits when I charge royalties for their use.

TroyK Received on Thu Jan 03 2008 - 19:18:22 CET

Original text of this message