Search code examples
databasedatabase-designprimary-keyidentifierleast-astonishment

Why is negative id or zero considered a bad practice?


Why is negative id or zero considered a bad practice when inserting a primary key in a database table?

I think it could be useful in some cases, but people say that it is not recommended, despite the fact that they never say/know why.

So, I was wondering if is there, by definition, some restriction or if it shouldn't have any problem or if is it just a convention and if really there is some restriction about that, why isn't that feature blocked?


Solution

  • To be clear, this question and answer are about using negative numbers for surrogate keys, not for natural keys.

    As far as I know, there are three reasons for considering it to be a bad practice.

    1. It violates the principle of least surprise.
    2. Some people assume all ID numbers are non-negative.
    3. Some people use negative numbers to indicate errors.

    The first one has some validity to it. You never see SQL examples or answers on SO that use negative ID numbers. (I'm going to change that, starting today.)

    The second and third are corollaries to the first, in that programmers often assume surprise-free behavior. (That reminds me of discovering that VBA would let me multiply two dates, returning a number that would be expressed, I guess, in square dates.)

    For number 2, application programmers might introduce subtle errors by not allowing room for the sign in UI code, which might make -123456 look like 123456.

    The third has to do with writing code that returns id numbers. Code that returns a single id number might return -1 as an error code. But -1 is a valid ID number in most cases. (Most databases don't restrict id numbers to the range of non-negative integers.)