PHP Developers Network

A community of PHP developers offering assistance, advice, discussion, and friendship.
It is currently Tue May 23, 2017 3:45 am

All times are UTC - 5 hours

Post new topic Reply to topic  [ 2 posts ] 
Author Message
PostPosted: Thu Apr 23, 2015 2:59 pm 
Forum Newbie

Joined: Thu Apr 23, 2015 2:51 pm
Posts: 1
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, but I need guidance.

Here is a sample id of what I'd like to get.
Syntax: [ Download ] [ Hide ]
$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.

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.
Syntax: [ Download ] [ Hide ]
DECLARE jObjectCount BIGINT(20);
DECLARE jObjectId CHAR(3);
SELECT id, totalInserts INTO jObjectId, jObjectCount FROM jObject WHERE name = pObjectName;

Triggers on my tables (example table name: myTableName)
A before insert trigger that calls the function to get the id
Syntax: [ Download ] [ Hide ]
   SET = RecordIdGenerate('myTableName');

An after insert trigger to update my jObject table with the total number of inserts it's undergone:
Syntax: [ Download ] [ Hide ]
UPDATE jObject SET totalInserts = totalInserts + 1 WHERE name = 'myTableName';

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.

PostPosted: Sat Apr 25, 2015 4:27 pm 
Site Administrator
User avatar

Joined: Wed Aug 25, 2004 7:54 pm
Posts: 13396
Location: New York, NY, US
Not sure I am clear on everything you are asking, but two thoughts:

1. It seems like like totalInserts could be an autoincrement ID in the actual table instead of in jObject. That would certainly make things more atomic rather than fetching a counter an then later updating that counter.

2. If you know the name if the table before hand, it seem like you could everything in the INSERT. It probably requires a TRIGGER to get the autoincrement during the INSERT, but you could probably build the ID in one query.


Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 2 posts ] 

All times are UTC - 5 hours

Who is online

Users browsing this forum: No registered users and 4 guests

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Jump to:  
Powered by phpBB® Forum Software © phpBB Group