Re: Love or hate, or? domains with cardinality two

Op woensdag 18 november 2015 10:10:04 UTC+1 schreef Nicola:
> ...
> >
> > Okay so that was too hasty of me.
> >
> > (DEPARTMENT NOTMATCHING (EMPLOYEE WHERE mgr)) SUBSET-OF FI
> >
> > addresses it, methinks. Still nowhere near "not straightforward" in my
> > book ...
>
> Point taken.
>
> This highlights the importance of the succintness of the language, not only the
> expressiveness. Constraints expressed algebraically are in many cases
> more succint
> than their counterpart in first-order logic (think of division).

I have been "hatching" quite a bit on a [polite] way to express that your "non-straigthforwardness" was actually not in the constraint, but in the language used by formal logic to express it.

It is easy to deduce from "all departments must have exactly one manager" that "departments at fault are those that have no manager at all, or more than one". And while you _NEED_ logic to underpin that deduction, the language of logic itself is actually actively alienating/obstructive to making it. At least to an engineer whose profile perhaps doesn't fit the targeted audience of this group. This group being the theory group.

In my personal opinion, which I am exceptionally going to label explicitly as "humble", that might very well be the reason why Datalog is not [and never will be] the solution to the "problem" of relational databases. (I know full well what amount of flak I'll get over such pronouncements in academic circles.)

> SQL is nowhere near that,

I would hope that anyone around here knows that. (Hmmmmmmmm one particularly vociferous exception already comes to mind.)

> and when I think of something not being
> straightforward,
> my opinion is biased by the thought that it needs to be eventually
> implemented in SQL.

I have put myself without an income for 6/7 years to show that it is not the case that "eventually it must be implemented in SQL".

> That said, my argument is still valid: using a different schema design
> would allow
> you to simplify the above constraint even further, so it is correct
> that the above
> is not the *most* straightforward constraint ;)

My mind is insufficiently clear on this subject (it was crystal clear as fresh water prior to those 6/7 years). Tailoring designs so constraints become expressible declaratively, does not seem like a very good idea, unless you are constrained by the limitations of SQL implementations that do not have CREATE ASSERTION.

But if you have CREATE ASSERTION (and knowing that CREATE ASSERTION is all you need to keep all necesssary "control" over any form of "redundancy"), what motivation remains to stick with normalization theory as being relevant ?

If you have CREATE ASSERTION, and knowing that it adds an extra twist to the notion of "simplicity" as advocated by the normal forms (because it then becomes possible to have a 1NF db structure that still gives all the integrity guarantees provided by the equivalent BCNF structure), what is the notion of "simplest design" to pursue ? Received on Thu Nov 19 2015 - 19:46:28 CET