2009-09-09 13 views
27

¿Cuál es el propósito de nombrar sus restricciones (único, clave principal, clave externa)?¿Cuál es el propósito de la restricción nombrar

Decir que tengo una tabla que está utilizando claves naturales como clave principal:

CREATE TABLE Order 
(
    LoginName  VARCHAR(50) NOT NULL, 
    ProductName  VARCHAR(50) NOT NULL, 
    NumberOrdered INT   NOT NULL, 
    OrderDateTime DATETIME  NOT NULL, 
    PRIMARY KEY(LoginName, OrderDateTime) 
); 

¿Qué beneficios (si los hay) no nombrar mi PK llevar?

Por ejemplo. Reemplazar:

PRIMARY KEY(LoginName, OrderDateTime) 

Con:

CONSTRAINT Order_PK PRIMARY KEY(LoginName, OrderDateTime) 

Lo siento si mi modelo de datos no es la mejor, soy nuevo en esto!

+1

quizás usar el nombre para referirse a la restricción más tarde .. como cuando desea eliminar \ edit it? – Aziz

Respuesta

62

Aquí hay algunas razones bastante básicas.

(1) Si una consulta (insertar, actualizar, eliminar) infringe una restricción, SQL generará un mensaje de error que contendrá el nombre de la restricción. Si el nombre de la restricción es claro y descriptivo, el mensaje de error será más fácil de entender; si el nombre de la restricción es un nombre aleatorio basado en guid, es mucho menos claro. Particular para los usuarios finales, que (de acuerdo, podría) llamarlo y preguntar qué significa "FK__B__B_COL1__75435199".

(2) Si una restricción necesita ser modificada en el futuro (sí, sucede), es muy difícil de hacer si no sabe cómo se llama. (ALTER TABLE MyTable drop CONSTRAINT um ...) Y si crea más de una instancia de la base de datos "desde cero" y usa nombres predeterminados generados por el sistema, no habrá dos nombres que coincidan.

(3) Si la persona que admite tu código (también conocido como DBA) tiene que perder mucho tiempo tratando con el caso (1) o el caso (2) a las 3 am del domingo, es muy probable que en una posición para identificar de dónde vino el código y poder reaccionar en consecuencia.

+1

+1 cubre todas las bases – gbn

4

Para identificar la restricción en el futuro (por ejemplo, desea dejarla caer en el futuro), debe tener un nombre único. Si no especifica un nombre, el motor de la base de datos probablemente le asignará un nombre raro (por ejemplo, que contenga elementos aleatorios para garantizar la exclusividad).

+0

¿Esto significa que la denominación solo se usa para que las personas puedan identificar una restricción más fácilmente? En otras palabras, no importa (ni afecta) el DBMS de ninguna manera, ya sea que usted nombre una restricción o no? ¿No puedes usarlo en el código para algún propósito? Lo siento si eso no estaba claro. – Andrew

+1

Es solo un nombre. El nombre no hace una diferencia funcional. Si desea hacer referencia en el código en el futuro, el nombre importa, por supuesto. Es como decir, un nombre de variable en el código. –

+1

Al igual que los * nombres de columna * no hacen la diferencia. Si describen lo que son ("ProductId" en lugar de "BJZ0_340" o "Fred"), son mucho más útiles. –

1

Ayuda a alguien a saber rápidamente qué restricciones están haciendo sin tener que mirar la restricción real, ya que el nombre le brinda toda la información que necesita.

Por lo tanto, sé si es una clave principal, clave única o clave predeterminada, así como la tabla y posiblemente columnas involucradas.

3

Mantiene contentos a los DBA, por lo que permiten la definición de su esquema en la base de datos de producción.

+0

Jaja ... sí, creo que esta es la razón más importante: P – Andrew

3

Cuando su código viola al azar alguna restricción de clave externa, seguro que ahorra tiempo en la depuración para averiguar cuál era. Nombrarlos simplifica enormemente la depuración de sus insertos y sus actualizaciones.

1

Al nombrar correctamente todas las restricciones, puede asociar rápidamente una restricción particular con nuestro modelo de datos. Esto nos da dos ventajas reales:

  1. Podemos identificar rápidamente y corregir cualquier error.
  2. Podemos modificar o eliminar las restricciones de manera confiable.
Cuestiones relacionadas