create table basket_impossible (
customer varchar (48) not null
references customer(name),
ord integer as
(select count(*) from basket_impossible as self
where basket_impossible.customer = self.customer),
-- other columns
primary key (customer, ord)
)
Let's see how this table would work
Insert into basket_impossible(customer) values(1);
(1, 0);
Insert into basket_impossible(customer) values(1);
(1, 0), (1, 1)
update basket_impossible set customer = 2 where customer = 1 and ord = 0;
(2, 0), (1, 1)
Insert into basket_impossible(customer) values(1);
(2, 0), (1, 1), (1, 1)
which produces primary key violation.
Also I don't quite understand how the concept of natural keys differs
from the concept of candidate keys.
It seems that it's only meaning is to contrast a candidate key - that
comes "naturally" from the
problem area being modeled without adding any extra columns - with a
surrogate key.
Eg. the ISBN code of a book, url of an internet resource etc.
Your solution seems to be exactly adding extra columns that do not
derive their meaning from
the issue being modeled and thus would be more accurately called a
surrogate key.
- rami
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/h2-database?hl=en.
