En el trabajo tenemos una gran base de datos con índices únicos en lugar de las claves principales y todo funciona bien.

Estoy diseñando una nueva base de datos para un proyecto nuevo y tengo un dilema:

En DB de la teoría, la clave principal es elemento fundamental, que es aceptable, pero en proyectos REALES ¿cuáles son las ventajas y desventajas de ambos?

Qué utilizar en los proyectos?

EDICIÓN: …¿y qué acerca de las claves principales y replicación en MS SQL server?

InformationsquelleAutor Cicik | 2009-01-28

15 Comentarios

  1. 157

    ¿Qué es un índice único?

    Un único índice en una columna es un índice en la columna que también impone la restricción de que no puede haber dos iguales valores en esa columna en dos filas diferentes. Ejemplo:

    CREATE TABLE tabla1 (int foo, bar int); 
    CREATE UNIQUE INDEX ux_table1_foo EN la tabla1(foo); -- Crear un índice único en foo. 
    
    INSERT INTO tabla1 (foo, bar) values (1, 2); -- OK 
    INSERT INTO tabla1 (foo, bar) values (2, 2); -- OK 
    INSERT INTO tabla1 (foo, bar) values (3, 1); -- OK 
    INSERT INTO tabla1 (foo, bar) values (1, 4); -- No! 
    
    Entrada duplicada '1' clave 'ux_table1_foo' 
    

    La última inserción falla porque viola el único índice de la columna foo cuando intenta insertar el valor 1 en esta columna para un segundo tiempo.

    En MySQL una restricción unique permite varios valores Nulos.

    Es posible hacer un índice único en varias columnas.

    Clave primaria versus índice único

    Cosas que son de la misma:

    • Una clave primaria implica un índice único.

    Cosas que son diferentes:

    • Una clave principal también implica NO NULO, pero un índice único que acepta valores null.
    • Sólo puede haber una clave primaria, pero puede haber varios índices únicos.
    • Si no hay ningún índice agrupado definido, entonces la clave principal será el índice agrupado.
    • Tenga en cuenta que Un único índice es un índice en una columna no es del todo exacto como un índice único o clave principal puede incluir más de una columna.
    • Jasmin: gracias Fijos. La parte acerca de varias columnas se menciona más adelante.
    • Lástima que me perdí
    • Con referencia a los nulos, los estándares ansi permitir varios valores null en un conjunto de datos con una única restricción sobre ella, y que es también la implementación de Oracle y PostgreSQL. Creo que SQL Server sólo permite un valor nulo, aunque.
    • pero todavía no me di cuenta, como por ejemplo, cuando el uso de la clave principal o cuando el uso de índice único ? o puede ser ambas cosas a la en las mismas situaciones.
  2. 30

    Se puede ver como este:

    Una Clave Principal ES Único

    Un valor Único no tiene que ser la Representación del Elemento

    Significado?; Bien una clave principal se utiliza para identificar el elemento, si usted tiene una «Persona» que le gustaría tener un Número de Identificación Personal ( número de seguro social o de tales ) que es Primordial para su Persona.

    Por otro lado, la persona podría tener una dirección de e-mail que es único, pero doensn no identificar a la persona.

    Siempre tengo las Claves Primarias, incluso en relación de tablas ( la mitad de la tabla /tabla de conexión que pueda tener de ellos. Por qué? Así me gusta seguir una norma a la hora de la codificación, si la «Persona» tiene un identificador, el Coche tiene un identificador, bueno, entonces la Persona -> Coche debe tener un identificador así!

    • En su relación de tablas: ¿te refieres a introducir una nueva columna con una artificial clave principal (un entero, por ejemplo) o no puede utilizar un compuesto clave principal (person_id, car_id)?
    • primary key (person_id, car_id) sería la mejor. Pero yo en general, crear una nueva columna, seguro que le da algo de sobrecarga, pero he considerado como siendo buena. Nunca se sabe si se desea relacionar a una relación específica más adelante en un escenario.
    • La otra cosa el sustituto de la clave principal para el material compuesto/de unirse a la mesa es la facilidad de mantenimiento de las tareas manuales.
    • Sólo se necesita una clave principal si vas a tener hijos. ¿Por qué añadir una columna y una secuencia, si el valor que aparece en ninguna parte, si el valor es utilizado para nada? Es hacer el trabajo con el fin de detener el Acceso de pedir un PK. Hacer un PK si usted necesita para identificar el registro de un niño, de lo contrario es una pérdida.
    • No, No tirar primay claves sólo porque usted no tiene hijos, y nunca se sabe si el sistema crece grande y un día realmente necesitan relaciones. Un Primay clave se utiliza para determen qué campo es el PRINCIPAL, inicialmente no tiene nada que ver con las relaciones.
    • Si no tiene nada que ver con las relaciones, ¿qué tiene que hacer con el? Elija un campo y decir, que la primaria. Y? Entonces, ¿qué sucede? Y si no hay ningún naturales pk, puedo agregar una columna y una secuencia y un gatillo y todo porque ____? Algunos sólo necesita ser Primaria. Yo prescinden de reglas sin razones.

  3. 8

    Claves externas trabajo con las únicas limitaciones así como las claves primarias. De Libros En Línea:

    Una restricción FOREIGN KEY no tiene
    esté vinculada únicamente a una CLAVE PRINCIPAL
    restricción en otra mesa; se puede
    también se puede definir a la referencia de la
    columnas de una restricción UNIQUE en
    otra tabla

    Para la replicación transaccional, necesita la clave principal. De Libros En Línea:

    Las tablas publicadas para transaccional
    la replicación se debe tener una clave primaria.
    Si una tabla está en una transaccional
    publicación de replicación, usted no puede
    deshabilitar cualquiera de los índices que son
    asociado con columnas de clave principal.
    Estos índices son necesarios para
    la replicación. Para deshabilitar un índice, que
    primero debe quitar la tabla de la
    publicación.

    Ambas respuestas son para SQL Server 2005.

    • QUE asusta el infierno fuera de mí (primera cita). Por qué? Tengo una persona de la tabla con un IDENTIFICADOR arbitrario que es mi PK pero me decido a agregar en el reino unido al Teléfono, Correo electrónico, & SSN… así que ahora 4 mesas unirse a la persona en 4 columnas? Creo que me gustaría renunciar a cualquier flexibilidad que usted puede conseguir la consistencia.
  4. 5

    La elección de cuándo usar un sustituto de la clave principal en contraposición a una clave natural es complicado. Respuestas tales como, siempre o nunca, rara vez son útiles. Me parece que depende de la situación.

    Como un ejemplo, tengo las siguientes tablas:

    CREATE TABLE toll_booths (
        id            INTEGER       NOT NULL PRIMARY KEY,
        name          VARCHAR(255)  NOT NULL,
        ...
        UNIQUE(name)
    )
    
    CREATE TABLE cars (
        vin           VARCHAR(17)   NOT NULL PRIMARY KEY,
        license_plate VARCHAR(10)   NOT NULL,
        ...
        UNIQUE(license_plate)
    )
    
    CREATE TABLE drive_through (
        id            INTEGER       NOT NULL PRIMARY KEY,
        toll_booth_id INTEGER       NOT NULL REFERENCES toll_booths(id),
        vin           VARCHAR(17)   NOT NULL REFERENCES cars(vin),
        at            TIMESTAMP     DEFAULT CURRENT_TIMESTAMP NOT NULL,
        amount        NUMERIC(10,4) NOT NULL,
        ...
        UNIQUE(toll_booth_id, vin)
    )

    Tenemos dos tablas de entidad (toll_booths y cars) y una tabla de transacción (drive_through). El toll_booth tabla utiliza una clave suplente porque no tiene ningún atributo natural que no está garantizado para cambiar (el nombre puede ser cambiado fácilmente). El cars tabla de usos natural de la clave principal porque tiene un no-cambio de identificador único (vin). El drive_through tabla de transacciones utiliza un sustituto clave para una fácil identificación, pero también tiene una restricción unique en los atributos que son únicos a la hora de insertar el registro.

    http://database-programmer.blogspot.com tiene algunos grandes artículos sobre este tema en particular.

  5. 4

    No hay desventajas de las claves primarias.

    Para añadir algo de información para @MrWiggles y @Peter Parker respuestas, cuando la tabla no tiene clave primaria, por ejemplo, usted no será capaz de editar los datos en algunas aplicaciones (que va a terminar diciendo algo como no se puede editar /borrar datos sin la clave principal). Postgresql permite varios valores NULL a ser en una ÚNICA columna de CLAVE PRINCIPAL no permite valores Nulos. También algunos ORM que generan código puede tener algunos problemas con las tablas sin necesidad de claves primarias.

    ACTUALIZACIÓN:

    Que yo sepa no es posible replicar las tablas sin necesidad de claves primarias en MSSQL, al menos sin problemas (detalles).

    • Hay una sobrecarga cuando se inserten nuevas filas o columna que se actualiza .
  6. 2

    Si algo es una clave principal, dependiendo de su motor de base de datos, toda la tabla se presenta ordenados por la clave primaria. Esto significa que las búsquedas son mucho más rápidos en la clave principal ya que no tiene que hacer ninguna de eliminar, ya que tiene que ver con cualquier otro tipo de índice. Además de eso, es sólo teoría.

    • la mesa se ve ordenadas por el índice agrupado no neccesarily por la clave principal.
    • se da la circunstancia de que la mayoría de la gente conjunto de su clave principal para ser el índice agrupado.
    • Lo que sabemos es a menudo una Muy Mala Idea, a menos que, como hot-spots y desequilibrada índice de árboles en nuestras mesas, por supuesto…
    • No SIEMPRE es una Idea Realmente Mala. Saber sus datos, conocer su RDBMS, saber cuáles son las opciones significan. Rara vez es la elección SIEMPRE es bueno o malo. Si SIEMPRE fue una, la base de datos mandato o deshabilite. Te dan a elegir, porque ‘Depende’.
  7. 2

    Siempre que no permiten valores NULL para un valor, que debe ser manejada de la misma, pero el valor NULL se maneja de forma diferente en las bases de datos(AFAIK MS-SQL no permite más de una(1) valor NULL, mySQL y Oracle permiten esto, si una columna es ÚNICO)
    Así que debe definir esta columna not NULL UNIQUE INDEX

    • MS-SQL no permite varios valores NULL en una columna que tiene un índice único, como cada RDBMS. Piénsalo de esta manera: NULL no es un valor, por lo que cuando se inserta un segundo NULL, nunca va a coincidir con uno existente. La expresión (NULL == NULL) no evalute a true o false, se devuelve NULL.
    • gracias gregmac, yo no estaba seguro de que, si MS que sigue. Me acordé de algunos MS Peculiaridades con esto, sin embargo, algunos años antes(pre 2000) y también podría ser un acceso de edad-DB tos
    • +1 @gregmac Null == Null Null.
    • href=»http://technet.microsoft.com/en-us/library/ms187550.aspx» >technet.microsoft.com/en-us/library/ms187550.aspx
  8. 2

    No hay tal cosa como una clave principal de datos relacional de la teoría, por lo que su pregunta tiene que ser contestada en el nivel práctico.

    Índices únicos no son parte del estándar SQL. La implementación concreta de un DBMS va a determinar cuáles son las consecuencias de la declaración de un índice único.

    En Oracle, declarando una clave principal se traducirá en un índice único ser creado en su nombre, así que la pregunta es casi irrelevante. Yo no puedo decirle a usted acerca de otros productos DBMS.

    Estoy a favor de la declaración de una clave principal. Esto tiene el efecto de prohibir valores Nulos en la columna de clave(s) así como prohibir los duplicados. Yo también a favor de declarar REFERENCIAS para hacer cumplir las restricciones de integridad de entidad. En muchos casos, declarar un índice en el coulmn(s) de una clave externa aumentará la velocidad de la une. Este tipo de índice, se debe en general a no ser único.

    • Una clave principal en MS SQL Server siempre es ÚNICO y NO NULO – por ejemplo, es en realidad un índice Único, pero con la restricción adicional de que no puede ser NULL.
    • Oracle puede aplicar una Restricción Unique con un índice no único. Me sorprendería si MSSS no podía. Diciendo: «es realmente un índice único» es un flaco favor.
    • «En muchos casos, declarar un índice en el coulmn(s) de una clave externa aumentará la velocidad de la une.» esto es casi siempre no es cierto en un almacenamiento de datos mundial donde las combinaciones hash sería preferible si está disponible.
    • El OP no mencionar a los almacenes. No estoy seguro de cómo hash lomos de trabajo en sql server. La cantidad de obra que se puede hacer en la bodega el tiempo de actualización.
  9. 1

    Además de lo que las otras respuestas han dicho, algunas bases de datos y sistemas de mayo de requieren una primaria para estar presente. Una situación que viene a la mente; cuando el uso de la empresa de replicación con Informix un PK deben estar presentes para que una tabla a participar en la replicación.

  10. 1

    Yo casi nunca crear una tabla sin un numérico de la clave principal. Si también hay una clave natural que debe ser único, yo también puse un índice único en él. Las combinaciones son más rápidos en enteros de varias columnas naturales claves, los datos sólo se necesita cambiar en un solo lugar (claves naturales tienden a ser necesario actualizar lo cual es una mala cosa cuando se está en la clave principal de relaciones de clave externa). Si usted va a tener la replicación de usar un GUID en lugar de un número entero, pero para la mayor parte prefiero una clave que es fácil de leer, especialmente si se necesita ver para distinguir entre John Smith y John Smith.

    Las pocas veces que no estoy de crear un sustituto de la clave cuando tengo una de unirse a la mesa que está involucrado en muchos-a-muchos de relación. En este caso, declaro que en ambos campos de la clave principal.

    • «Yo casi nunca crear una tabla sin un numérico de la clave principal»: ¿por qué siempre numérico? Una clave principal no necesita ser numérico (ni necesita ser AUTO_INCREMENT por el camino).
    • porque he encontrado que las claves naturales rara vez son únicas y que son casi siempre cambiante. Furthere une en intergers son generalmente mucho más rápido que los une en varcahrr claves naturales o peor claves compuestas. Yo no los uso nmost de la época. Esto puede hacer variar el tipo de información que almacena en su base de datos, pero en mi experiencia personal he encontrado naturales claves para ser muy fiable en el tiempo.
    • Gracias por la respuesta HLGEM. ¿A qué te refieres con poco fiable? El rendimiento? (Espero que no es una cuestión de fiabilidad en el sentido de la integridad de los datos). Estoy un poco sorprendido por sus palabras, como yo, aunque el uso de claves de enteros o más claves naturales como corto de tipo VARCHAR, es probable que los hace tan sólo una pequeña diferencia algoritmos de hash se utiliza en todas partes, incluso con el más simple de motores de base de datos.
    • Son poco fiables en muchos casos porque ellos no son la única forma fiable incluso a pesar de que se supone que debe ser. Son poco fiables porque ellos cambian y que puede afectar a millones de registros en un uopdate. Esta es mi experiencia de haber visto y haber gestionado o datos consultados o importados de datos de cientos de bases de datos que almacenan los datos acerca de los muchos diferentes tipos de información.
  11. 1

    Hay algunas desventajas de los ÍNDICES AGRUPADOS vs ÍNDICES ÚNICOS.

    Como ya se ha dicho, un ÍNDICE AGRUPADO físicamente las órdenes de los datos en la tabla.

    Esto significa que cuando usted tiene un montón si inserta o elimina en una tabla que contiene un índice agrupado, cada vez que (bueno, casi, dependiendo de su factor de relleno) de cambiar los datos, la tabla física necesita ser actualizado para mantenerse ordenados.

    En relación pequeñas tablas, esto está muy bien, pero al llegar a las tablas que se han GB de datos, y insertrs/elimina afectar a la ordenación, que se ejecutará en problemas.

    • ¿Cuál es la ventaja, entonces? ordena las consultas son más rápidos? es mejor para un caso de uso cuando usted escribe la mayoría de sus datos una vez (o rara vez) y consultar con él todo el tiempo?
  12. 1

    Mi entendimiento es que una clave principal y un índice único con un no‑null constraint, son las mismas (*); y supongo que elegir uno u otro dependiendo de lo que la especificación declara de manera explícita o implícita (una cuestión de lo que quieres expresar de forma explícita y hacer cumplir). Si se requiere una singularidad y no nulo, luego hacen una clave principal. Si sucede de todas las partes de un índice único no‑nulo, sin ningún requisito para que, a continuación, sólo tienes que hacer un índice único.

    La única diferencia es que usted puede tener múltiples no‑nulos índices únicos, mientras que usted no puede tener varias claves primarias.

    (*) A excepción de una diferencia práctica: una clave principal puede ser el valor predeterminado de la clave única para algunas operaciones, como la definición de una clave externa. Ex. si uno define una clave externa que hace referencia a una tabla y no proporciona el nombre de la columna, si la referencia de la tabla tiene una clave primaria, luego la clave principal será la referencia de la columna. De lo contrario, la referencia de la columna deberá ser nombrado de forma explícita.

    Otros que aquí se han mencionado DB de replicación, pero yo no sé acerca de ella.

  13. 0

    Único Índice puede tener un valor NULO. Crea ÍNDICE NO AGRUPADO.
    Clave principal no puede contener un valor NULL. Se crea un ÍNDICE AGRUPADO.

  14. 0

    En MSSQL, las claves Primarias deben ser monótonamente creciente para un mejor desempeño en el índice agrupado. Por lo tanto, un entero con la inserción de identidad es mejor que cualquier clave natural que podría no ser monótona creciente.

  15. -1

    Si fuera por mí…

    Que necesita para satisfacer los requisitos de la base de datos y de las aplicaciones.

    La adición de un incremento automático integer o long id de columna de cada tabla para servir como clave primaria se ocupa de los requisitos de base de datos.

    A continuación, añadir, al menos, otro índice único para la tabla para el uso de la aplicación. Este sería el índice de id_empleado, o account_id, o customer_id, etc. Si es posible, este índice no debe ser un índice compuesto.

    Yo estaría a favor de índices en varios campos de forma individual sobre índices compuestos. La base de datos va a utilizar el único campo de índices, siempre que la cláusula where incluye los campos, pero sólo se hará uso de un compuesto cuando se proporcionan los campos exactamente en el orden correcto – lo que significa que no puede usar el segundo campo en un índice compuesto, a menos que se proporcione tanto la primera y la segunda en la cláusula where.

    Yo soy todo para el uso calculado o el tipo de Función de los índices y recomienda que se utilicen más de índices compuestos. Esto hace que sea muy fácil de usar la función de índice utilizando la misma función en la cláusula where.

    Este se lleva la atención de los requerimientos de su aplicación.

    Es muy probable que otros no principales índices son en realidad las asignaciones de que los índices de valor de la clave para un valor de clave principal, no rowid()’s. Esto permite física de las operaciones de ordenación y elimina a ocurrir sin tener que volver a crear estos índices.

Dejar respuesta

Please enter your comment!
Please enter your name here