Why is negative id or zero considered a bad practice?

Question

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?

Answer 1

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

Answer 2

The answer by @Mike Sherrill 'Cat Recall' is IMHO incorrect.

Negatives: The reason for not using negatives for IDs is that negative numbers are not portable. The binary representation of a decimal value depends on the underlying numerical architecture, and this effects the way a negative decimal value will be presented in non-negative, streamed format (e.g., hex, base36, etc.). Similarly one doesn't use floating point values as identifiers, even though within the constraints of a single architecture it is theoretically possible.

Zero: Zero can serve as an ID. It is not recommended though because it often denotes an empty field / NULL value.

Answer 3

There are more than 51 million sites discussing this problem.

I agree with @Mike Sherrill and it is likely common that NULLs/Empty fields or Negative Ids create severe problems in determining the true values. It serves no informational purpose at all, and can only lead to incorrect answers and distrust in the database itself.

Allowing Zero values,Negative values into your columns introduces a whole new degree of uncertainty into your database. guesses must be made by the SQL programmer to counter for erroneous results of NULL values in a database.