Primary Key Attraction
I have a boss (as well as users) who wants the primary key to be a complex / smart / attractive control number (sort of like a social security number or a credit card number format)
I simply added a primary key (in Views) with zeros to appease their desire to make the control number complex, smart and attractive. But they wanted it to be: the first 2 digits as the client code, then 4 digits per year, and then the last 4 digits as the transaction number on this client for this year, and then reset the client transaction number to 1, when next year, each customer transaction begins with 1. for example. WM20090001, WM20090002, BB2009001, WM20100001, BB20100001
But since I wanted to make everything as simple as possible, I refuse to implement the proposed intelligence in the primary key, I just keep the automatic growth of the primary key regardless of the client and year. But in order to make it not boring (they are really adamant to make the primary key as an intelligent control number), I made the primary key smart for them, in the presentation of the request I put the client code and the four-digit year code in the foreground of the octagonal auto-increment key, i.e. WM200900000001 . Slug-like sorting of auto-increment primary key information.
By saving the auto-increment of the primary key, regardless of any other information, we can save other potential side effects when editing the record, for example, if they made a mistake when entering the transaction to WM, then they change the client code to BB, if we use an intelligent primary key , the primary keys of the WM client will have spaces in the control numbers. Or, even worse, instead of allowing control numbers to have gaps / holes, users will request that subsequent entries of these spaces should shift to these gaps and transfer the primary keys of subsequent entries (decreased).
- How do you deal with these user requests (reasonable or others)?
- Do you succumb to their request?
- Or just keep using a dumb primary key and explain to them the consequences of having a very smart / complex primary key and introduce them to the important benefits of having a dumb primary key?
PS
quotable quote ( https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1044961.html ):
"If you keep your language first, users ask what a reasonable request is for them, everything will work much better in the end."