RE: System wide unique keys, use a 16 byte character or 4 4 byte integers.

We have to stay away from Informix specifics like serial values, allthough our platform is designed and sold for the Informix engine we need to offer the ability to attach our software to any database vendor product. As far as the bottleneck of OID allocation, we recognize that this will pose problems. We have decided, as the article suggests, to give out a range of unique values to each process that requests them. This way a process can grab a range of OIDs and increment them internally. When it runs out, it would ask the range server for another range. Thanks for your input on this, Andrew -----Original Message----- From: Andrew Hamm [SMTP:ahamm@sanderson.net.au] Sent: Monday, December 11, 2000 7:20 PM To: informix-list@iiug.org Subject: Re: System wide unique keys, use a 16 byte character or 4 4 byte integers. Andrew Ford wrote in message <913sef$n2o$1@news.xmission.com>... > >All, > >We are currently looking at generating system wide unique keys to help us >track our data (as per an article written by Scott Ambler at >http://www-4.ibm.com/software/developer/library/mapping-to-rdb/ ) > >The primary key for every table will be a 16 byte integer, the foreign keys >will reference this number. > >The paper suggests using a 16 byte character to hold the hex representation >of a very large number. We were concerned about the overhead of comparing >strings vs. using 4 4 byte integers to hold the value of this large number. > Can anyone add to our train of thought, is the processor overhead of >containing this unique identifier as a string greater than the composite >index overhead of using 4 4byte integers as a primary key. > >I know this is a vague question, we just wanted to see if anyone else out >there has implemented a system like this and if there were any >pitfalls/advantages to this scheme that we had not thought of. > >Thanks, > >Andrew Sounds like too much hard work, and for me it misses the directness of representing the data directly. You'll probably find that Informix serial numbers (32bit) will be a sufficient supply of object numbers anyway, although there will be repeats of the same key from different tables. But apart from knowing the heirarchy, how could you find exactly which table to look for an anonymous OID? So the serial number would be fine for the job since the implicit disambiguating of the relations will supply the complete identification. Unless you are extremely careful in the allocation of OID's, you will have a DEADLY bottleneck which will kill the scalability of your application. Even a good allocation routine will suffer scaling problems. If you are designing an object-based application, and if you want to use the Informix engines, why not learn and stick with the object-relational facilities offered by the Universal server (and the 2000 incarnation of the same engine). I would expect that in the long run you will get a better fit with your data if you actually exploit the strengths of your chosen engine instead of patching up an alternative methodology. That article you reference appears to focus on putting objects into a strictly releational engine. Go one better and use the object-relational engine.