Why is *.number not unique by default?

[johnsgp]

I have noticed numerous questions in the forum about duplication of incident numbers, task numbers, CI numbers, knowledge numbers, and so on.

Often these questions involve discussions of fix scripts that are not quite working.

One of the more interesting comments is in Re: Duplicate incidents are created with same incident number but different sys_id? where Mack Peace wrote:

This issue is caused when users double click the "Submit" button.   From what I understand this is a known issue and the way to prevent it is to make the ticket number "unique".

It seems to me to be an unnecessary leniency to allow duplication in what should be a key field. In particular, task.number (and all its inherited tables) and kb_knowledge.number as a minimum should be unique in all new instances to ensure that the double-clicking of the Submit button issue is addressed.   I understand that older instances might not easily be upgraded to uniqueness due to existing duplication, so I do not expect these to be upgraded automatically.

Does anyone know why the number fields are not unique by default in new instances?  

[Volker2]

I don't understand this default behavior either, and it is still present in the NewYork release. In my opinion this is a really bad design decision, because it can create a lot of rubbish data and destroy your data model. And what can happen, will happen. Everyone talks about how important it is to have clean data - and what does ServiceNow? Exactly the opposit! Not understandable ...

Also the fact with the child tables and same number prefix: just don't do this. It would be a really bad design anyway, so ServiceNow should prohibit same number prefixes for different tables!

I mean why is there a number field if you can't trust it anyway? Correct use of primary keys is the first thing you learn when developing databases.