[GNUe-dev] Unique IDs in GNUe Appserver

[Jan Ischebeck]

Hi Reinhard,

I'm more and more convinced that gnue appserver shouldn't depend on
unique ids stored in the database. I would prefer that the unique ids
needed for the rpc communication between server and client should be
dynamicly created instead.

A pro of not depending on our "gnue-id" flag would be that no database
table conversion (for postgres: ALTER TABLE X ADD gnue_id
CHAR(32);UPDATE X SET gnue_id=OID) wouldn't be needed anymore, if you
switch form 2-tier to 3-tier.

Below a short comment on unique ids found on IBM Developerworks
(http://www-106.ibm.com/developerworks/web/library/wa-dbdsgn1.html)


> The problem of the Universally Unique Identifier
> 
> A final consideration concerns the possible need for a Universally
> Unique Identifier (UUID). The short answer is that relational
> databases do not require UUIDs at all. In fact, the entire UUID
> concept is somewhat unrelated to relational database management.
> Relational database keys -- the plumbing -- need only be unique per
> table, which can be achieved by using an auto-incrementing datatype
> such as the serial type mentioned earlier.
> 
> UUIDs can have some technical difficulties. To ensure uniqueness, all
> UUIDs must be generated by a centralized service -- which leads to
> scalability problems and can become a single point of failure. (The
> scalability issue can be mitigated by a stratified approach in which a
> central master is used to give out seeds to several slaves, which in
> turn generate the final identifiers in batches, and so on.) To
> represent a UUID in a database, use either a string attribute or a
> compound key comprising several integer columns. Both approaches are
> significantly slower than operations based on keys made up of long
> integers. Compound keys also increase the complexity of the DB schema
> when used as foreign keys.
> 
> In the end, whether or not a record in a database needs to have a
> truly globally unique ID is dictated by the business rules, not the
> database architecture. Some records may already contain some form of
> UUID (merchandise items, for instance, typically possess a Universal
> Product Code as barcode). Some other records, possibly corresponding
> to principal business entities, may otherwise already contain a unique
> identifier as part of their business data (such as the combination of
> timestamp and account name for a ledger entry). If this is not the
> case, a UUID can be generated and stored alongside the business data
> for those records that require it. In any case, UUIDs should be
> considered part of the business data -- not of the plumbing.
> 
> Even if (and this is a big if) the object-relational mapping approach
> chosen requires every business object to have a persistent, unique ID,
> there is no need to base the internal workings of the underlying
> relational database engine on this fact.
> 
> In summary, I argue to keep business data apart from the database's
> internal plumbing. Building a relational database around UUIDs breaks
> this principle by using attributes, which, in the end, are really part
> of the business data, as internal infrastructure. (For a totally
> different point of view on this issue and a careful discussion of the
> problems involved in generating UUIDs in a scalable fashion, see Scott
> Ambler's paper, "Mapping objects to relational databases," in
> Resources.)

Jan

-- 
Jan Ischebeck <address@hidden>