GUID Factory

[Jean-David Beyer]

Christopher Browne wrote (in part):
> 
> This is something that is indeed appropriately generated in the "engine,"
> not in the DB; the relevance to the DB is to ask whether it can use the
> GUID as one of its keys, and whether or not the DB supports foreign keys.

What is this "foreign key" stuff? I know what a "foreign key" is, and do
not see how the concept applies here. If you want to stick a GUID into a
record, tuple, or whatever you want to call it, you may do so, of
course. If you search based (at least in part) on that field, column,
attribute, or whatever you want to call it, often enough, it may be
appropriate to make an index on that. Most relational DBMSs permit
indexing any field (unless it is considered "large", perhaps, but I
cannot imagine the GUID would be large). But that decision need not be
made until you know enough about the retrieval requirements of the
system to make that decision. One nice thing about using a rdbms is that
such decisions can be deferred indefinately, and changed from time to
time without changing the applications running against the database at
all.

Whether you consider that field to be a foreign key or not depends on
whether or not it is the primary key of another table, relation, or
whatever you want to call it. Even then, you would not need to declare
it to be a foreigh key unless you want to enforce the relationship
between the two tables (which you probably should).

Or am I missing something?

-- 
 .~.  Jean-David Beyer           Registered Linux User 85642.
 /V\                             Registered Machine    73926.
/( )\ Shrewsbury, New Jersey
^^-^^ 8:40pm up 13 days, 5:28, 2 users, load average: 3.64, 3.51, 3.31