Thus spake The Hermit Hacker
> > OIDs are a bastardization of the relational model. If you have to keep
> > them, then do so, but their use should be SEVERELY discouraged.
I agree although I do use them in some library routines (Tcl and Python)
that I use in a get/update cycle. The way it is set up though, the calling
routine is never aware of the use of OIDs. It's almost like part of the
database engine as far as the routine is concerned.
example:
from pg import *
from dbgen import *
db = connect('table')
user = db_get(db, 'user', 100)
user['name'] = 'Joe'
db_update(db, 'user', user)
The db_get puts the oid into the Python dictionary and the db_update uses
that to update the same record. The caller never sees it.
Note: Of course I realize that a simple SQL statement will do this. It's
a contrived example.
> Actually, I use them quite extensively...I have several WWW-based
> search directories that are searched with:
>
> select oid,<fields> from <table> where <search conditions>;
>
> That display minimal data to the browser, and then if someone
> wants more detailed information, I just do:
>
> select * from <table> where oid = '';
But really there should be a proper key on this database. I think that
that's what Karl was getting at. If you need a unique ID number then
you should really create one and make it a unique index on the table.
> Its also great if you mess up the original coding for a table and
> want to remove 1 of many duplicates that you've accidently let pass
> through :(
With unique keys this shouldn't really be a problem. In fact, the entire
record can be a complex key if necessary (I have done this on small
tables) so it should always be possible. If you can still get dups
with the entire record keyed then just add an extra, non-keyed field
which holds the count.
--
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.