Question

Do you ever use a separate table for “generating” artificial primary keys for DB (and why)? What I mean is to have a table with two columns, table name and current ID – with which you could get new “ID” for some table by simply locking the row with that table name, getting the current value of the key, increment it by one, and unlock the row. Why would you prefer this over standard integer identity column?

P.S. The “idea” is from Fowlers Patterns of Enterprise Application Architecture, btw…

Answer 1

This is called Hi/Lo assignment.

You would do this having either a trigger on INSERT on your tables getting the ID from this table and incrementing it before or after you get your ID, depending of your choice.

This is commonly used when you have to deal with multiple database engines. The autoincremental identifier in Oracle is through a SEQUENCE, which you increment with SEQUENCE.NEXTVALUE from within a BEFORE INSERT TRIGGER on your data table.

Oppositly, SQL Server has IDENTITY columns, autoincrementing natively and this is managed by the DBE itself.

In order for your software to work on both DBE, you have to come to some sort of a standard, then the most common “standard” used for this is the Hi/Lo assignment to the primary key.

This is one approach amongst others. These days, with ORM Mapping tools such as NHibernate, it is offered through configuration so that you need less to care on both the application and the database sides.

EDIT #1

Because this kind of maneuvre can’t be used for a global scope, you’d have to have such a table per database, or database schema. This way, each schema is indenpendant from the other. However, data in one schema can’t implicitly be moved toward another with the same key, as it would perhaps be conflicted with an already existing row.

As for a security schema, it accesses the same database as another schema or user, so no additional table should exist for specific security schema.