¿Por qué es id negativos o cero se considera una mala práctica a la hora de 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 del hecho de que ellos nunca dicen/sé por qué.

Así, me preguntaba si es que hay, por definición, algunos de restricción o si no debería tener ningún problema o si es sólo una convención, y si realmente hay restricción alguna acerca de que, ¿por qué no esa característica bloqueado?

  • ¿Tienes algo para documentar esta «mala práctica»? Me imagino números negativos son más desagradables de leer, y un poco más difícil de escribir. Yo realmente no puedo ver ninguna razón técnica para evitarlos. De hecho, es una gran manera de ampliar la gama de firmarse un tipo de datos.
  • En el lateral, esto es útil cuando se crean registros en el cliente que más tarde debe ser insertado en el servidor: msdn.microsoft.com/en-us/library/ms971502.aspx
  • Supongo que es popular que los números negativos son ‘considera’ una ‘mala práctica’, algo ‘feo’ para ‘evitar’. ¿No es así? Pero realmente no puedo ver por qué… Entonces, @Puaj, usted cree que es debido a la legibilidad?
  • Algunos de discusión en dba stackexchange que puede dar un poco de perspectiva. dba.stackexchange.com/questions/2895/… no estoy muy seguro de una buena razón para no usarlos, sin embargo.
  • Encontrado algo acerca de .NET (no es lo que yo uso, pero otros podrían utilizar esa información): stackoverflow.com/q/2473215/1064325
InformationsquelleAutor falsarella | 2012-01-19

3 Comentarios

  1. 26

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

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

    1. Viola el principio de la menor sorpresa.
    2. Algunas personas asumen todos los números de IDENTIFICACIÓN son no negativos.
    3. Algunas personas el uso de los números negativos para indicar errores.

    La primera tiene cierta validez a la misma. Nunca se ve a SQL ejemplos y respuestas de MODO que el uso negativo de los números de IDENTIFICACIÓN. (Voy a cambiar eso, a partir de hoy.)

    El segundo y el tercero son corolarios a la primera, en la que los programadores a menudo asumen sorpresa libre de comportamiento. (Que me recuerda a descubrir que VBA me permitiría multiplicar dos fechas, la devolución de un número que se expresa, supongo, en la plaza de fechas).

    Para el número 2, los programadores de aplicaciones pueden introducir errores sutiles no permite la entrada de la sala para la sesión en la interfaz de usuario código, que podría hacer que -123456 mirar como 123456.

    La tercera tiene que ver con la escritura de código que devuelve los 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 restringir los números de id para el rango de enteros no negativos.)

    • Tener en cuenta estos motivos de la misma por cero, o es que hay algo diferente?
    • Mismo por cero, creo. En algunos lugares utilizan 0 como una especie de no-null reemplazo de NULL.
    • Ninguna restricción a continuación, 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 este? ¿Cómo se maneja?
    • En este contexto, números de identificación deben identificar a una persona, y eso es todo. Si usted también desea saber si una persona es un admin, almacenar su número de identificación en un «administradores» de la tabla.
    • A veces es cómodo de usar cero-id de registro en una tabla para tener otras tablas de referencia como un valor predeterminado. Se simplifica el control de situaciones de error cuando no existe registro de la otra tabla se hace referencia. Especialmente cuando las claves externas no son estrictamente marcada, como en el motor MyISAM en MySQL. Con el motor InnoDb – también evita el bloqueo de consultas.
    • así que es una buena idea utilizar negativo de identificación para indicar errores en una tabla de referencia, por ejemplo id: -1, message: error id: 1, message: OK?
    • El OP pregunta y mi respuesta se acerca claves de suplente. Voy a editar mi respuesta para hacer esto más claro. Por definición, las claves suplentes no tienen sentido. Pero el uso de los números negativos para la media de errores en una tabla de códigos de estado es completamente diferente del caso de uso. En que contexto, los números negativos son claves naturales, no claves suplentes; que no son del todo sorprendentes.

  2. 9

    La respuesta por @Mike Sherrill ‘Gato Recordar’ en mi humilde opinión es incorrecta.

    Negativos: La razón para no usar los negativos de los Identificadores es que los números negativos no son portables. La representación binaria de un valor decimal depende del subyacente numérico de la arquitectura, y esto afecta la manera en que un negativo valor decimal será presentado en la no-negativo, transmitido en formato (p. ej., hex, base36, etc.). Del mismo modo que uno no se utilizan los valores de punto flotante como identificadores, aunque dentro de las limitaciones de una única arquitectura es teóricamente posible.

    Cero: Cero puede servir como un ID. No es recomendable, porque aunque a menudo denota un campo vacío o NULO valor.

    • Buen punto. +1. ¿Tienes alguna de las fuentes al respecto? Nunca el pensamiento de la representación de la arquitectura, pero aún así tiene un problema de portabilidad para el resto de los tipos de campo, de todos modos… por lo tanto, el principio de la menor sorpresa parece todavía más relevante de la razón.
    • Formalmente, un identificador es un token (hay un buen resumen en en.wikipedia.org/wiki/Identifier), por lo que un número negativo podría ser considerado un token sólo si usted lo considera como una secuencia de caracteres, que tipo de desafíe su naturaleza como «negativo». Así, en el contexto de su pregunta, donde el IDENTIFICADOR es un número y no de una cadena, este número de no servir como un ID cuando es negativo. Esto no es sólo una recomendación, como en el caso de «principio de la menor sorpresa», es, en mi humilde opinión un error usar un IDENTIFICADOR negativos. Tal vez el más extremo ejemplo de uso de flotadores como IDs es más intuitivo.
    • Creo que hay varias maneras de copia de seguridad y puerto de una base de datos. Binario de copia de seguridad/la portabilidad es una opción, pero no estamos restringidos a ella. El verdadero error sería confiar en la arquitectura física para copia de seguridad o algo puerto. Como he mencionado, en caso de que sucediera, la portabilidad sería un problema para cualquier otro transportables columnas. Para resolver por el PK en realidad no resuelve nada. Su declaración no se aplica sólo para los PKs, se aplica a cualquier número de la columna, por lo que sería un error usar en cualquier lugar si un negativo es permitido, que es realmente sin sentido.
    • No hay ningún problema real en la copia de seguridad y la portabilidad ya que en estos casos la codificación está bajo control. El problema comienza cuando se utiliza el ID en una interfaz. Es un esquema común, por ejemplo, para los Identificadores de tener un ancho fijo de caracteres en la base, como una manera de validar el valor de ID. Pero usted no puede hacer eso con números negativos, a menos que el esquema especifica la codificación de los números negativos: LSB o. MSB, que complementan o dos complementar, etc., que no es práctico. Este no es el mismo que el de un campo de datos debido a un campo de datos es sólo el número, no es un símbolo.
    • Tal vez esto va a ser más sencillo: supongamos que tenemos un elemento con ID «-10». Si usted interpretar la IDENTIFICACIÓN de tres bytes que consiste en la representación ascii de guión-uno-cero, entonces no hay problema, este es un documento de identidad válido. Sin embargo, si usted desea este ID para ser tratado como un número (en este punto se encuentra en el núcleo de la cuestión), su segmentación es no-ambiguo sólo como una firma de decimales. No se pueden acortar y sin ambigüedades en cualquier otra representación común, salvo que se especifique un número específico de la arquitectura, sin perder la meta de su valor numérico.
    • Teniendo en cuenta que sólo estoy hablando sobre el uso de un largo número como clave principal en algunos de base de datos, segmentación binaria en ese contexto parece muy exagerada. En cualquier caso, gracias por tu contribución!
    • Creo que el binario de la segmentación es un estándar en los Identificadores, por ejemplo, OID, UUID, etc. No acabo de ver por qué uno guarda en una base de datos de un ID que no se puede usa como la interoperabilidad de la IDENTIFICACIÓN. Después de todo, con n bits puede representar 2^n valores, no importa si su largo es firmada o sin firmar. Entonces, ¿para qué considerar el uso de un entero con signo de una IDENTIFICACIÓN?

  3. 0

    Hay más de 51 millones de sitios de la discusión de este problema.

    Estoy de acuerdo con @Mike Sherrill y es probable que los valores Null/campos Vacíos o Negativo de los Identificadores de crear graves problemas en la determinación de los valores verdaderos. No sirve a ningún propósito informativo a todos, y sólo puede conducir a respuestas incorrectas y la desconfianza en la propia base de datos.

    Permitiendo que los valores Cero,los valores Negativos en sus columnas presenta un nuevo grado de incertidumbre en su base de datos. adivina debe ser hecha por el programador de SQL para contador de resultados erróneos de valores NULL en una base de datos.

Dejar respuesta

Please enter your comment!
Please enter your name here