Re: partial "on-delete set null" constraint

W dniu 04.01.2015 o 02:02, Alban Hertroys pisze:
[------------------------------]
>
> "A table can have at most one primary key, but it may have more than one candidate key. A primary key is a combination of columns which uniquely specify a row; it is a special case of unique keys. One difference is that primary keys have an implicit NOT NULL constraint while unique keys do not."
>
> They blatantly leave out why primary keys have that implicit NOT NULL! Is this some forgotten about piece of database theory? I’ll have to ask my teachers where they got their definition from!
>

I'd say, that this is because it's a definition. "primary key" is
defined that way: they,ve chosen a name ("primary") and features (a
unique key over not null attributes, and no other key using a name of
"primary"), and that's it. And the goal for such definition was possibly
also quite trivial: it's for the programmers like ourselves to
communicate efficiently what we mean.

I'm still not convinced of how the "norm/specs/theory" expect engine to
treat inconsistent constraint setup. In this case, the setup is
inconsistent: "on delete set null" contradicts "not null" attribute. So:
should the engine rise an error (like it does), or should it just humbly
comply with the setup, and only do what's allowed by the setup, i.e.:
skip the "not null" columns when executing "on delete" action.

-R