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

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

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 haber ningún problema o si es solo una convención y si realmente hay alguna restricción al respecto, ¿por qué no es esa característica? ¿obstruido?

Fuente

2012-01-19 falsarella

¿Tiene algo para documentar esta "mala práctica"? Imagino que los números negativos son más desagradables de leer y algo más difíciles de escribir. Realmente no veo ninguna razón técnica para evitarlos. De hecho, es una forma excelente de ampliar el rango de un tipo de datos firmado. – Yuck

En el lado, esto es útil cuando se crean registros en el lado del cliente que luego se deben insertar en el servidor: http://msdn.microsoft.com/en-us/library/ms971502.aspx – Niklas

Supongo que es popular que los números negativos son 'considerados' una 'mala práctica', algo 'feo' para 'evitar'. ¿No es así? Pero realmente no puedo ver por qué ... Entonces, @Yuck, ¿crees que es debido a la legibilidad? – falsarella

Para ser claros, esta pregunta y respuesta se refieren al uso de números negativos para claves sustitutas, no para claves naturales.

Hasta donde yo sé, hay tres razones para considerar que es una mala práctica.

Viola el principle of least surprise.
Algunas personas asumen que todos los números de identificación no son negativos.
Algunas personas usan números negativos para indicar errores.

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

El segundo y el tercero son corolarios del primero, ya que los programadores a menudo asumen un comportamiento libre de sorpresas. (Eso me recuerda que descubrí 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 podrían introducir errores sutiles al no permitir espacio para el código de UI de inicio de sesión, que podría hacer que -123456 se parezca a 123456.

El tercero tiene que ver con escribir código que devuelve números de identificación. El código que devuelve un único 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 números enteros no negativos.)

Fuente

2012-01-21 19:14:04

Consideras que estas razones son las mismas para cero o hay algo diferente? – falsarella

Igual para cero, creo. Algunos lugares usan 0 como una especie de reemplazo no nulo para NULL. –

Sin restricciones, ¡gracias! El problema será el código de implementación. Pero ... ¿Qué pasa con el uso de -1 para los usuarios administradores o algunas constantes como esta? ¿Cómo manejas? – falsarella

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

Negativos: El motivo por el que no se utilizan negativos para los ID 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 la forma en que se presentará un valor decimal negativo en formato no negativo, transmitido (por ejemplo, hexadecimal, base36, etc.). De manera similar, uno no usa valores de coma flotante como identificadores, aunque dentro de las limitaciones de una única arquitectura es teóricamente posible.

Zero: Zero sirve como ID. Sin embargo, no se recomienda porque a menudo denota un campo vacío/valor NULL.

Fuente

2015-12-29 18:08:39 avnr

Buen punto. +1. ¿Tienes alguna fuente al respecto? Nunca pensé en la arquitectura de representación, pero de todos modos seguiría teniendo un problema de portabilidad para el resto de los tipos de campo ... Por lo tanto, el principio de menor sorpresa aún parece una razón más relevante. – falsarella

Formalmente, un identificador es un token (hay una buena descripción general en https://en.wikipedia.org/wiki/Identifier), por lo que un número negativo podría considerarse un token solo si lo considera como una secuencia de caracteres, que tipo de desafía su naturaleza como "negativa". Entonces, en el contexto de su pregunta, donde la ID es un * número * y no una cadena, este número * no debe * servir como ID cuando sea negativo. Esto no es solo una recomendación como en el caso "principio de menor sorpresa", es, en mi humilde opinión, un error utilizar una identificación negativa. Quizás el ejemplo más extremo de usar flotadores como ID sea más intuitivo. – avnr

Creo que hay varias formas de realizar copias de seguridad y portar una base de datos. La copia de seguridad/portabilidad binaria es una opción, pero no estamos limitados a ella. El verdadero error sería confiar en la arquitectura física para realizar copias de seguridad o portar algo. Como mencioné, en caso de que ocurriera, la portabilidad seguiría siendo un problema para cualquier otra columna no portátil. Entonces resolverlo para el PK en realidad no resolvería nada. Su extracto no se aplica solo a PK, se aplica a cualquier columna numérica, por lo que sería un error usarlo en cualquier lugar si se permite un negativo, lo que en realidad no tiene sentido. – falsarella

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

Estoy de acuerdo con @Mike Sherrill y es probable que los campos NULLs/Empty o Negative Ids creen serios problemas para determinar los valores verdaderos. No tiene ningún propósito informativo y solo puede generar respuestas incorrectas y desconfianza en la base de datos.

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 realizar conjeturas para contrarrestar los resultados erróneos de los valores NULL en una base de datos.

Fuente

2015-12-29 20:04:19 vrn53593

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

Respuesta

Cuestiones relacionadas