secundaria - ¿Es necesaria una clave principal en SQL Server?
llave secundaria sql (10)
¿Necesario? No. ¿Usado detrás de escena? Bueno, se guarda en el disco y se guarda en el caché de la fila, etc. Si lo quita, aumentará ligeramente su rendimiento (use un reloj con precisión de milisegundos para darse cuenta).
Pero ... la próxima vez que alguien necesite crear referencias a esta tabla, te maldecirán. Si son valientes, agregarán un PK (y esperarán mucho tiempo para que el DB cree la columna). Si no son valientes o tontos, comenzarán a crear referencias utilizando la clave comercial (es decir, las columnas de datos) lo que provocará una pesadilla de mantenimiento.
Conclusión: dado que el costo de tener un PK (incluso si no se usa ATM) es muy pequeño, déjelo.
Esta puede ser una pregunta bastante ingenua y estúpida, pero voy a preguntar de todos modos
Tengo una tabla con varios campos, ninguno de los cuales es único, y una clave principal, que obviamente lo es.
A esta tabla se accede a través de los campos no únicos de forma regular, pero no a los datos de acceso del proceso o del SP del usuario a través de la clave principal. ¿Es la llave primaria necesaria entonces? ¿Se usa detrás de escena? ¿Eliminarlo afectará el rendimiento positiva o negativamente?
¿Tiene alguna clave extranjera? ¿Alguna vez se unió al PK?
Si la respuesta a esto es no, y su aplicación nunca recupera un elemento de la tabla por su PK, y ninguna consulta lo usa en una cláusula where, por lo tanto, acaba de agregar una columna de IDENTIDAD para tener un PK, entonces:
- el PK en sí mismo no agrega ningún valor, pero tampoco daña
- el hecho de que PK es muy probable que el índice agrupado también lo sea ... depende .
Si tiene índices NC, el hecho de tener una clave agrupada artificial (IDENTITY PK) es útil para mantener esos índices estrechos (la clave CDX se reproduce en cada ranura de hoja CN). Entonces, un PK, incluso si nunca se usó, es útil si tiene índices NC significativos.
Por otro lado, si tiene un patrón de acceso prevalente, una determinada consulta que supere a todas las demás es la frecuencia e importancia, o que es parte de una ruta de código de tiempo crítico (por ejemplo, es la consulta ejecutada en cada visita de página en su sitio , o cada segundo por y aplicación, etc.) entonces esa consulta es un buen candidato para dictar el orden de las teclas agrupadas.
Y, por último, si rara vez se consulta la tabla, pero a menudo se escribe, puede ser un buen candidato para un HEAP (sin clave agrupada) ya que los montones son mucho mejores en las inserciones. Consulte Comparación de tablas organizadas con índices agrupados versus montones .
Como dijo SQLMenace, el índice agrupado es una columna importante para el diseño físico de la tabla. Además, tener un índice agrupado, especialmente uno bien elegido en una columna delgada como un entero pk, en realidad aumenta el rendimiento de inserción.
En el modelo lógico, una tabla debe tener al menos una clave. No hay ninguna razón para especificar arbitrariamente que una de las claves es ''primaria''; todas las llaves son iguales. Aunque el concepto de "clave primaria" se remonta al trabajo inicial de Ted Codd, el error que se recogió temprano se ha corregido durante mucho tiempo en la teoría relacional.
Tristemente, PRIMARY KEY encontró su camino hacia SQL y hemos tenido que vivir con eso desde entonces. Las tablas SQL pueden tener filas duplicadas y, si considera que el conjunto de resultados de una consulta SELECT también es una tabla, las tablas SQL también pueden tener filas duplicadas. A los teóricos relacionales no les gusta mucho el SQL. Sin embargo, solo porque SQL te permite hacer todo tipo de cosas extrañas no relacionales, eso no significa que realmente tengas que hacerlas. Es una buena práctica asegurarse de que cada tabla SQL tenga al menos una clave.
En SQL, usar PRIMARY KEY por sí solo tiene implicaciones, por ejemplo, NOT NULL , UNIQUE , la referencia predeterminada de la tabla para claves externas. En SQL Server, usar PRIMARY KEY por sí solo tiene implicaciones, por ejemplo, el índice agrupado de la tabla. Sin embargo, en todos estos casos, el comportamiento implícito puede hacerse explícito utilizando una sintaxis específica.
Puede usar UNIQUE (restricción en lugar de índice) y NOT NULL en combinación para aplicar claves en SQL. Por lo tanto, no, una clave principal (o incluso PRIMARY KEY ) no es necesaria en SQL Server.
La clave principal, cuando está definida, ayudará a mejorar el rendimiento dentro de la base de datos para la indexación y las relaciones.
Siempre tiendo a definir una clave primaria como un entero autoincrementado en todas mis tablas, independientemente de si tengo acceso o no, esto se debe a que cuando comienzas a escalar tu aplicación, es posible que realmente la necesites, y hace la vida mucho más simple.
Nunca tendría una mesa sin una clave principal. Supongamos que alguna vez necesita eliminar un duplicado: ¿cómo identificaría cuál eliminar y cuál conservar?
Si está accediendo a ellos a través de campos no clave, el rendimiento probablemente no cambie. Sin embargo, sería bueno mantener el PK para futuras mejoras o interfaces a estas tablas. ¿Tu aplicación solo usa esta única tabla?
Un PK no es necesario.
Pero debe considerar colocar un índice no único en las columnas que usa para consultar (es decir, que aparecen en la cláusula WHERE). Esto aumentará considerablemente el rendimiento de búsqueda.
Una clave principal es realmente una propiedad de su modelo de dominio e identifica de manera única una instancia de un objeto de dominio.
Tener un índice agrupado en una columna monótonamente creciente (como una columna de identidad) significará que las divisiones de página no ocurrirán, PERO las inserciones desequilibrarán el índice a lo largo del tiempo y por lo tanto la reconstrucción de índices debe hacerse de manera regular (o cuando la fragmentación alcanza un cierto umbral) .
Tengo que tener una muy buena razón para crear una tabla sin una clave primaria.
La clave principal es detrás de las escenas de un clustered index (de forma predeterminada a menos que se genere como un índice no agrupado) y contiene todos los datos de la tabla. Si el PK es una columna de identidad, las inserciones se realizarán secuencialmente y no se producirán divisiones de página.
Pero si no accede a la columna de ID en absoluto, entonces probablemente quiera agregar algunos índices en las otras columnas. Además, cuando tienes un PK puedes configurar las relaciones FK