Relational theory doesn't encourage the use of an arbitrary rowid
(or for that matter, synthetic keys like IDENTITY fields). In fact
the inclusion of one breaks the logic of relational algebra.
Consequently SQL doesn't define one, and SQL server doesn't
implement one.

Not that that ever stopped anyone (myself included) from using them.
The performance effects (mainly from reduced record size in
referencing tables) are too dramatic to avoid using them much of
the time.

 > SQL Server still *uses* a globally unique id to refer to each row
 > in a database

Not always true. In the case of clustered indices, the rowid *is* the
key value; there *is* no database rowid in the conventional sense.
If you search on a secondary index, you find a primary key value
and must search on *that* to find the record :-(. Ugly, slow, but
sometimes (rarely!) the right thing to do.

ActiveRecord should be adapted to use the synthetic key if one exists,
or the primary key if one exists, else any other unique identifier,
even maybe failing over to "all fields", which is the minimum required
by the relational algebra.

This is what our Ruby-based data layer code generator does. It's
gorgeous if I do say so myself; a 2000 line Ruby program with 4800 lines
of templates and a schema description file of 2000 lines (excluding
embedded documentation) generates print-redy documentation and 150,000
lines of C#, C++, SQL, Web Services server and client stubs, and soon,
Java. Pity the company doesn't see it as a saleable item :-(.

BTW, interesting idea using Ruby as the schema description language.
It wouldn't work for us (we need at least five other languages generated
from the one source), but it is kinda cute.

Clifford Heath.