Re: Functional Dependencies > Uniqueness Constraints

From: Jan Hidders <hidders_at_gmail.com>
Date: 5 Sep 2006 14:11:34 -0700
Message-ID: <1157490694.262017.123650_at_i3g2000cwc.googlegroups.com>


Marshall wrote:
> Jan Hidders wrote:
> > Marshall wrote:
> > > >
> > > > Obviously a DBMS that can express general FDs can express more than one
> > > > that can just express CKs, except if you alway normalize to BCNF. But
> > > > that doesn't mean there shouldn't be a special notion of CK.
> > >
> > > Special notion or special notation?
> >
> > Both. Having this notion makes things easier for the user (DKs are
> > easier to understand for most people than FDs)
>
> The user concerns can be fully addressed notationally. (In other
> words, it's easy enough to have a notation for a CK that
> expands into an FD in the kernel language.)

Ok.

> > and for the DBMS (CKs
> > are important for indexes and are easier to maintain then general FDs).
>
> Sure, but in general optimizing for ease of implementation is the
> wrong choice in code that is going to be the foundation for
> lots of other code.

Agreed, but there is a trade-off here: adding extra complexity to this foundation code may also lead to extra bugs and overhead.

But you are also right that the algorithm isn't really that hard to get correct, and its time complexity is in terms of something that is usually not that big (the number of FDs, which btw. is not really the same as the number of CKs, as you seemed to imply), and not computed at "query execution time" but at "schema design time" so a high performance is not that essential anyway.

  • Jan Hidders
Received on Tue Sep 05 2006 - 23:11:34 CEST

Original text of this message