Generating base36 ids for records

[JayNic]

Hi guys,

 

I have some questions regarding how best to generate guaranteed non-repeating base36 ids for my records. I have many years experience in Salesforce APEX coding. As such, I'm extremely comfortable working with their id system.

I'd like to accomplish something similar in my personal WAMP framework.

 

Here is a sample id of what I'd like to get.

$myId = 'A0B00000000341K';

Some basic rules:

* The ids should always be 15 characters long.

* The Ids must be immutable

* The ids should never repeat. Even if I attempt to execute dml on records, and this results in an exception in my application - I will use transaction control to rollback the dml. Any ids generated and subsequently rolled back should never be used again.

* The first three characters of an id should represent the table where they belong. This way - I can determine what I am looking at based on whatever id I pass in. I can also validate foreign relationships on table by confirming the id being looked up to is of the appropriate type

 

 

So in the above example: I have an id belonging to a table with an id of A0B.

 

What I need guidance on

-- where the different parts of the business logic should live.

I have created a simple trigger system in mysql as a prototype. It looks as follows:

 

Table structure

I have a configuration table that stores some of the needed info.

Table: 'jObject'

Field: 'id' - The id of the jObject. In our above example - this would be 'A0B'

Field: 'name' - The Name of table with that id. for example: 'myTableName'

Field: 'totalInserts' - The total attempted inserted records in the table.

 

RecordIdGenerate

A mysql function to generate an id based on the table name you pass in. It finds a field called 'totalInserts' in another table - and updates it.

BEGIN
DECLARE jObjectCount BIGINT(20);
DECLARE jObjectId CHAR(3);
SELECT id, totalInserts INTO jObjectId, jObjectCount FROM jObject WHERE name = pObjectName;
RETURN CONCAT(
	jObjectId,
	LPAD(
		CONV(jObjectCount,10,36),
		12,
		'0000000'
	)
);
END

Triggers on my tables (example table name: myTableName)

SetRecordId:

A before insert trigger that calls the function to get the id

BEGIN
   SET NEW.id = RecordIdGenerate('myTableName');
END

UpdateTotalInserts:

An after insert trigger to update my jObject table with the total number of inserts it's undergone:

BEGIN
UPDATE jObject SET totalInserts = totalInserts + 1 WHERE name = 'myTableName';
END

What I don't like about this solution

1) It's not batchable. There are updates, and selects being done for every row inserted. This seems really inefficient, and bad practice.

2) I'm using base 36 ids to get away from the number of characters needed in base 10 ids, but I have to store a base 10 id in the jObject table to generate the base 36 id anyway... This seems wrong to me.

3) I don't know what happens if I rollback a transaction. Will the value placed in 'totalInserts' on jObject rollback too? My business rules say it should not...

4) I don't know how I can sort these ids... Do I need some special sorting function? Will it sort alphabetically - Ideally it shoudl sort by them numerically...

 

So basically. I guess I want to know if all this logic should be pushed to my php layer, and not the mysql layer. I feel like it should, but I want to know how best to meet my business requirements I mentioned above.

 

 

 

I really appreciate any insight.

Thanks

JayNic

Edited April 23, 2015 by JayNic

[Ofarchades]

Does your 15-digit ID really need to be the ID - or can it just represent the ID e.g. when displayed on screen?

 

It's generally advised (for all sorts of reasons) that IDs should be numeric and incremental. For example, some storage engines (such as MySQL's InnoDB) will physically organise the table such that primary keys are sorted in order. This means that if you're using non-sequential primary keys (which a base36 string would be), the table needs to be reorganised every time you enter a record - which could be a performance concern.

 

If I were you, I'd just have the ID be a regular integer in the database and have some logic in the code convert between the integer and your desired base36 format.

 

Regarding rollbacks: I don't think any DBMS will rollback incremental IDs. For example, if you create a row in MySQL and it's given an ID of 3, then rollback and create a new row, the new row will have an ID of 4, not 3.

Edited May 13, 2015 by Ofarchades