database - ¿Por qué la identificación negativa o cero se considera una mala práctica?

database-design primary-key

Question

¿Por qué la identificación negativa o cero se consideran una mala práctica al insertar una clave principal en una tabla de base de datos?

Creo que podría ser útil en algunos casos, pero la gente dice que no es recomendable, a pesar de que nunca dicen / saben por qué.

Entonces, me preguntaba si existe, por definición, alguna restricción o si no debería tener ningún problema o si es solo una convención y si realmente hay alguna restricción al respecto, ¿por qué no se bloquea esa función?

Answer 1

Hay más de 51 millones de sitios discutiendo este problema.

Estoy de acuerdo con @Mike Sherrill y es probable que los campos NULL / Empty o los Id. Negativos creen problemas graves para determinar los valores verdaderos. No tiene ningún propósito informativo y solo puede llevar a respuestas incorrectas y desconfianza en la base de datos.

Al permitir valores cero, los valores negativos en sus columnas introducen un nuevo grado de incertidumbre en su base de datos. el programador de SQL debe hacer las suposiciones para contrarrestar los resultados erróneos de los valores NULL en una base de datos.

Answer 2

La respuesta de @Mike Sherrill ''Cat Recall'' es IMHO incorrecta.

Negativos: la razón para no usar negativos para las identificaciones es que los números negativos no son portátiles. La representación binaria de un valor decimal depende de la arquitectura numérica subyacente, y esto afecta a la forma en que se presentará un valor decimal negativo en un formato de flujo no negativo (por ejemplo, hex, base36, etc.). De manera similar, uno no usa valores de punto flotante como identificadores, aunque dentro de las restricciones de una sola arquitectura es teóricamente posible.

Cero: Cero puede servir como una identificación. Sin embargo, no se recomienda porque a menudo denota un campo vacío / valor NULL.

Answer 3

Para ser claros, esta pregunta y respuesta son sobre el uso de números negativos para claves sustitutas, no para claves naturales.

Que yo sepa, hay tres razones para considerar que es una mala práctica.

1. Viola el principio de menos sorpresa .
2. Algunas personas asumen que todos los números de identificación no son negativos.
3. Algunas personas usan números negativos para indicar errores.

El primero tiene cierta validez. Nunca ve ejemplos o respuestas de SQL en SO que usen números de ID negativos. (Voy a cambiar eso, a partir de hoy.)

El segundo y el tercero son corolarios del primero, ya que los programadores a menudo asumen un comportamiento sin sorpresas. (Eso me recuerda a descubrir que VBA me permitiría multiplicar dos fechas, devolviendo un número que se expresaría, supongo, en fechas cuadradas).

Para el número 2, los programadores de aplicaciones pueden introducir errores sutiles al no dejar espacio para el código de UI de inicio de sesión, lo que podría hacer que -123456 se vea como 123456.

El tercero tiene que ver con escribir código que devuelve números de identificación. El código que devuelve un solo número de identificación puede devolver -1 como un código de error. Pero -1 es un número de identificación válido en la mayoría de los casos. (La mayoría de las bases de datos no restringen los números de identificación al rango de enteros no negativos).