How do I explain to users the benefits of a dumb primary key?

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."

+4
source share
4 answers

Is there any concatenation of keys that make a natural synthetic unique key? I believe not, or you will not ask a question.

Just as your user does not want to know the cylinder / block / head on which the record is stored, interest in it is not needed, but the primary key is not needed; This is an implementation detail. There are good reasons for a dumb primary key, but they are not business considerations. Hide details of the implementation of deaf keys behind the facade, which makes sense at the business level.

Explaining that they are bikeshedding probably won't work to your advantage. Pay attention to the expressed need of the client that your job.

+7
source

I approve of your small hand. You must meet the need for felt. Whenever possible, I explain that mental retention or understanding of data records is a need for a computer, and people should trust the machine and the system ... well, definitely not, but you get this idea. But often enough, I simply nod my head and give them what they think they need - but not as the key of the table, as they imagine. but at the request level.

In fact, my best work with databases - my current job - came to me mainly because the guy didn't understand this before me. He argued endlessly with managers about dumb numbers and adamantly refused to provide anything else. All I had to do was promise not to be like that.

+3
source

IMO, end users do not need to know the advantages / disadvantages of various types of primary keys.

The exact design and implementation of their data in the database should be seen as a black box for end users. The bottom line is that the output of this black box is the data in the correct format that they need: users do not need or need to know whether this field is really PK or generated from it.

0
source

According to Einstein, everything should be made as simple as possible, but not simpler. Simplicity in the eye of the beholder. If users find smart keys easier than dumb keys, you'll be good at placing them in views.

By continuing to use the dumb key in the base table, you avoid the few pitfalls that eventually arise when smart keys are used.

Knowledge is power. That is the data. When data becomes available, power becomes shared. When power is divided, politics happens. Diplomacy is part of the job.

0
source

Source: https://habr.com/ru/post/1307750/


All Articles