database-design - studio - superponer graficas en r

¿Por qué una sola clave primaria es mejor que las compuestas? (9)

¿Por qué el rechazo de las claves compuestas favorece a todas las tablas que usan una única clave primaria llamada id? Porque en general todos los ORM siguen esto.

EDITAR

Acabo de comenzar a aprender ruby on rails y en el libro de desarrollo ágil por pragmático hay una línea: --- Los rails realmente no funcionan muy bien a menos que cada tabla tenga una clave principal numérica. Es menos exigente sobre el nombre de la columna. El mismo tipo de línea que leí cuando estaba aprendiendo Doctrina.

EDIT2 Por favor, consulte este enlace también. Estoy cada vez más confundido acerca de esto: --- Claves primarias compuestas versus campo de ID de objeto único

Desde el enlace de arriba:

* la clave primaria debe ser constante y sin sentido; las claves no sustitutas generalmente fallan uno o ambos requisitos, eventualmente

Si la clave no es constante, tiene un problema de actualización en el futuro que puede complicarse bastante si la clave no tiene sentido, entonces es más probable que cambie, es decir, no sea constante; véase más arriba

Tomemos un ejemplo simple y común: una tabla de artículos de inventario. Puede ser tentador hacer que el número del artículo (número de SKU, código de barras, código de parte o lo que sea) sea la clave principal, pero un año después, todos los números de los artículos cambian y queda una actualización muy desordenada. problema de la base de datos ...

EDITAR: hay un tema adicional que es más práctico que filosófico. En muchos casos, vas a encontrar una fila en particular de alguna manera, luego la actualizas o la encuentras de nuevo (o ambas). Con las claves compuestas, hay más datos de los que realizar un seguimiento y más restricciones en la cláusula WHERE para la búsqueda o actualización (o eliminación). También es posible que uno de los segmentos clave haya cambiado mientras tanto. Con una clave sustituta, siempre hay un solo valor que retener (el ID sustituto) y, por definición, no puede cambiar, lo que simplifica la situación significativamente. *

Para un ORM, una sola columna de identificación con un nombre coherente como table_id es más fácil que una clave compuesta. Pero todo buen ORM soporta claves compuestas.
Un PK simple puede ser fácilmente "autoincrementado" por la base de datos. Esto no es válido para una clave compuesta.
Un PK simple también es más fácil de usar en las consultas. Cuando necesitas unirte, solo tienes que usar una columna de ambas relaciones.

Esto no quiere decir que las PK simples sean mejores que las compuestas, sin embargo.

Aunque estoy de acuerdo con la mayoría de las razones dadas por otros encuestados, mi principal razón para preferir una clave de entero de una sola columna es que hace que escribir una interfaz de usuario sea mucho más fácil.

Si está utilizando algún tipo de control de lista para representar sus datos (una lista, una vista de lista, un cuadro combinado, etc.), puede relacionar de manera única cada entrada con su representación de base de datos a través de un único valor entero almacenado con el elemento. La mayoría de los componentes escritos previamente le permiten adjuntar un número entero a cada elemento y, para aquellos que no lo hacen, es muy fácil extender el componente para hacerlo.

Si está pasando datos entre una aplicación de servidor y una página web, es mucho más fácil almacenar el único valor de identificación en el atributo id del widget que representa los datos que tener que redactar y analizar ids de múltiples valores.

Bueno, básicamente se trata de mantener los JOIN simples, cuál es más fácil de entender:

SELECT p.ID, p.Name, p.City, c.ID, c.Country, c.ISOCode FROM dbo.Parent p INNER JOIN dbo.Child c on c.ParentID = p.ID

SELECT p.ID, p.Name, p.City, c.ID, c.Country, c.ISOCode FROM dbo.Parent p INNER JOIN dbo.Child c ON c.ParentName = p.Name AND c.ParentCity = p.City AND c.ParentCountry = p.Country

Si tiene claves primarias compuestas, cualquiera que se una a su tabla desde una tabla secundaria debe "arrastrar" todas esas columnas, y todas esas columnas también estarán presentes en la tabla secundaria y las declaraciones de UNIÓN son bastante complicadas. Mucho mejor tener una sola clave (incluso sustituta) para la ÚNETE!

Los objetos en la programación OO tienen identidad independientemente de su contenido. Las filas (tuplas) en las bases de datos relacionales se identifican únicamente por su contenido. Por lo tanto, cuando realmente se hace ORM, es decir, se asignan objetos de un lenguaje de programación orientado a objetos a una base de datos relacional, se debe proporcionar un ID adicional como distinto de los campos y / o propiedades que el objeto tiene en el programa, a menos que uno o más de ellos sean De alguna manera se sabe que identifican objetos de forma única.

No creo que haya una declaración general de que solo se debe usar una sola clave primaria llamada id.

La mayoría de las personas usan una clave primaria sustituta como un generador automático de int, porque aísla la clave principal para que no sea necesario cambiarla, como si el PK fuera el nombre de usuario y luego cambiaran su nombre legal. Tendría que actualizar las columnas PK y todas las columnas FK para reflejar el nuevo nombre. Si ha usado una clave primaria sustituta, solo actualice el nombre del usuario en un lugar (porque las tablas se unen en el int no en el nombre).

El tamaño de una clave principal es importante porque la PK se duplica en cada índice que construye en la tabla. Si el PK es grande (como una cadena), tiene menos claves por página en el índice y el índice necesitará más memoria caché para almacenarlo. Los ints son pequeños.

Tener un incremento automático int PK se presta a ser un índice agrupado, ya que las filas se almacenan en este orden y no hay necesidad de retroceder y eliminar filas para insertar una nueva fila, siempre se agrega al final de la tabla .

Puedes usar ambos. En algunos casos, al hacer una asociación entre una entidad, puede usar ambas claves de entidad como una clave compuesta.

Como regla general, uso los ID generados para las entidades y las claves compuestas para las relaciones.

Su pregunta está fuertemente relacionada con la alternativa a las claves sustitutas (o artificiales) frente a las naturales . Creo que no es que las claves compuestas se utilicen menos, sino que las claves naturales (ya sean compuestas o simples) son menos favorecidas que las artificiales .

La teoría tradicional de la base de datos relacional trata principalmente con claves "naturales" (las que tienen un significado desde el punto de vista del dominio empresarial) y en ese escenario las claves compuestas se encuentran con frecuencia ... naturalmente.

Pero en los últimos años, el diseño de la base de datos ha favorecido (aunque no exclusivamente) el patrón de clave "artificial" (sustituto), generalmente un número secuencial que no tiene un significado comercial, solo sirve para identificar de forma única el registro en la tabla (y quizás el objeto). en la capa superior).

Trabajé en una aplicación con una clave primaria de 11 columnas. Siempre fue muy divertido volver a escribir la lista una y otra vez cada vez que quería garantizar que estaba actualizando una fila. Era un controlador de errores, MS-Access no podía hacer frente a más de 10 columnas en un PK, etc.

Las claves compuestas grandes son olores de diseño que significan que la tabla contiene entidades heterogéneas o que el diseñador no estaba realmente seguro de qué es lo que es único en cada entidad. (Por ejemplo, suponiendo que el color del cabello, el color de los ojos y el peso corporal sean suficientes para identificar a un empleado de forma exclusiva, lo cual no es una buena clave porque necesitaría más y más columnas para que funcione y, finalmente, eso incluirá campos) que son volátiles y cambian mucho, como el peso, o para algunas personas el color del cabello o la falta de él).

La única limitación real con la que me he topado con el uso de claves compuestas se refiere al uso de una expresión IN con una subconsulta. Esto es un problema, porque una subconsulta en una expresión IN debe devolver una sola columna (al menos en T-SQL).

SELECT emp.Name, emp.UserDomain, emp.UserID FROM employee emp WHERE ???? IN (SELECT e.UserDomain, e.UserID FROM ... /* some complex non-correlated subquery or CTE */ )

Siempre hay alternativas, por supuesto, pero a veces puede ser una molestia.

Esto no es una razón para evitar una clave compuesta en lugares donde tiene sentido usar una.