Thus spake Thomas G. Lockhart
> I'm not sure I understand all the issues, but if we can avoid
> distinctions between different indices that would be A Good Thing. Since
> multiple unique indices are allowed, what would be the extra
> functionality of having one designated "primary"? Is it an arbitrary
> SQL92-ism which fits with older databases, or something which enables
> new and interesting stuff?
Well, in database design there is a distinction between indeces and
keys. Being able to specify this distinction in the database seems
useful to me from a database designer perspective.
Here's how I use that distinction in my Python code.
data = db_get(db, customer, client_id)
data = db_get(db, province, data)
The first line gets the client record based on the client ID. The next
line gets the information on the client's province such as full name,
tax rate, etc. It does this because it knows that prov, the two letter
code field, is the primary key on province and it can find the prov
field in the data dictionary which came from the customer class. This
is similar to how some 4GLs do it.
FIND FIRST customer WHERE client_id = x, province OF customer.
Certainly there are alternate ways of doing this but it is nice to be
able to put as much information into the RDBMS as possible. Codd's
first rule might be used in support of this.
"All information represented only in tables."
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
