Primary key attractiveness
I have a boss(and also users) that wants primary key to be sophisticated/smart/attractive control number(sort of like Social Security number, or credit card number format)
I just padded the primary key(in Views) with zeroes to appease their desire to make the control number sophisticated,smart and attractive. But they wanted it as: first 2 digits as client code, then 4 digits as year year, then last 4 digits as transaction number on that client on a given year, then reset the transaction number of client to 1 when next year flows. Each client’s transaction starts with 1. e.g. WM20090001, WM20090002, BB2009001, WM20100001, BB20100001
But as I wanted to make things as simple as possible, I forgo embedding their suggested smartness in primary key, I just keep the primary key auto increments regardless of client and year. But to make it not dull-looking(they really are adamant to make the primary key as smart control number), I made the primary key appears to them smart, on view query, I put the client code and four digit year code on front of the eight-zero padded autoincrement key, i.e. WM200900000001. Sort of slug-like information on autoincremented primary key.
Keeping primary key autoincrement regardless of any other information, we are able keep other potential side effects problem when they edit a record, for example, if they made a mistake of entering the transaction on WM, then they edit the client code to BB, if we use smart primary key, the primary keys of WM customer will have gaps in their control numbers. Or worse yet, instead of letting the control numbers have gaps/holes, the users will request that subsequent records of those gaps should shift up to those gaps and have the subsequent records’ primary keys re-adjusted(decremented).
- How do you deal with these user requests(reasonable or otherwise)?
- Do you yield to their request?
- Or just continue using dumb primary key and explain them the repercussions of having a very smart/sophisticated primary key and educate them the significant advantages of having a dumb primary key?
P.S.
quotable quote( https://web.archive.org/web/1/http://articles.techrepublic%2ecom%2ecom/5100-10878_11-1044961.html ):
“If you hold your tongue the first
time users ask what is for them a
reasonable request, things will work a
lot better in the end.”
Is there some concatenation of keys that make a natural synthetic unique key? I suppose not or you’d not be asking the question.
In the same way that your user would not want to know the cylinder/block/head that the record of interest is stored on, they need not know the dumb primary key; it is an implementation detail. There are good reasons for a dumb primary key but they are not business reasons. Hide the implementation detail of dumb keys behind a facade that makes sense at the business level.
Explaining that they are bikeshedding will probably not work to your advantage. Address the expressed need of the customer, that’s your job.