database - proveedores - tabla productos sql

Decidir entre una clave primaria artificial y una clave natural para una tabla Productos

Question

Básicamente, necesitaré combinar datos de productos de múltiples proveedores en una sola base de datos (es más complejo que eso, por supuesto) que tiene varias tablas que deberán unirse para la mayoría de las operaciones de OLTP.

Iba a seguir con el valor predeterminado y utilizaría un entero auto-incremental como la clave principal, pero mientras un proveedor suministra su propio campo "ProductiD", el resto no y yo tendría que hacer una gran cantidad de mapeo manual al otro. luego las tablas para cargar los datos (ya que primero tendría que cargarlos en la tabla Productos, luego sacar la ID y agregar esa información junto con la otra información que necesito a las otras tablas).

Alternativamente, podría usar el SKU del producto como su clave principal, ya que el SKU es único para un solo producto, y todos los proveedores suministran un SKU en sus fuentes de datos. Si uso el SKU como PK, entonces podría cargar fácilmente las fuentes de datos ya que todo se basa en el SKU, que es como funciona en el mundo real. Sin embargo, el SKU es alfanumérico y probablemente será un poco menos eficiente que una clave basada en enteros.

¿Alguna idea sobre la que debería mirar?

Answer 1

Bastante similar a mi pregunta hace unos meses ...

¿Debo tener un campo de clave principal dedicado?

Fui con un PK de incremento automático al final.

Answer 2

El peligro siempre presente con claves naturales es que sus suposiciones iniciales se demostrarán incorrectas ahora o en el futuro cuando se realice algún cambio fuera de su control, o en algún lugar deberá hacer referencia a un registro donde no se pueda pasar un campo significativo. deseado (por ejemplo, una aplicación web que utiliza el número de seguridad social de un empleado como clave principal y luego tiene que usar direcciones URL como /employee.php?ssn=xxxxxxx)

Desde mi propia experiencia personal con los SKU "únicos" y las fuentes de datos de proveedores, ¿está absolutamente seguro de que le están enviando un feed con las SKU completas, únicas y bien formadas?

He tenido que lidiar personalmente con todo lo siguiente al obtener feeds de proveedores que tienen diferentes niveles de TI y competencia administrativa:

• Los productos faltan su SKU por completo ("")
• Los empleados han utilizado SKU de marcador de posición en su base de datos como 999999999 y 00000000 y nunca los corrigieron
• Aquellos que realizan el ingreso o la importación de datos se han confundido entre varios números de productos, mezclando cosas como UPC con SCC, o incluso encontrando formas de destrozarlos juntos (he visto códigos SCC con dígitos de verificación imposibles al final, porque simplemente copiaron el UPC y se agregó 01 o 10, sin corregir el dígito de control)
• Por razones especiales, o simplemente por incompetencia, el proveedor ha ingresado el mismo producto dos veces en su base de datos (por ejemplo, rev. 1 y rev. 2 de la misma placa base tienen el mismo SKU, pero existen como 2 registros en la base de datos de proveedores y en la fuente de datos). porque rev 2. tiene nuevas características)

Answer 3

En todas las situaciones internas, excepto en las más simples, recomiendo ir siempre por la clave sustituta. Le brinda opciones en el futuro y lo protege de incógnitas.

No hay ninguna razón por la que no se puedan crear claves adicionales, como un SKU, para hacerlas cumplir, pero al menos al eliminar su confianza en terceros, se está dando la opción de elegir, en lugar de quitarla de Tú y soportando una reescritura dolorosa en una etapa posterior.

Ya sea que vaya por el entero auto-incrementado o que determine la siguiente clave principal, habrá complicaciones. Con el método de incremento automático, puede insertar el registro fácilmente y dejar que asigne su propia clave, pero puede tener problemas para identificar exactamente qué clave recibió su registro (y no se garantiza que obtener la clave máxima le devuelva la suya).

Tiendo a buscar la clave autoasignada porque usted tiene más control y, en el servidor SQL, puede recuperar su clave de una tabla de claves central y asegurarse de que nadie más obtenga la misma clave, todo en una declaración:

DECLARE @Key INT

UPDATE  KeyTable
WITH    (rowlock)
SET @Key = LastKey = LastKey + 1
WHERE   KeyType = ''Product''

La tabla registra la última clave utilizada. El sql anterior incrementa esa clave directamente en la tabla y devuelve la nueva clave, asegurando su singularidad.

Por qué debes evitar las claves primarias alfanuméricas:

Tres problemas principales: rendimiento, colación y espacio.

Rendimiento: hay un costo de rendimiento, como Razzie a continuación, no puedo citar ningún número, pero es menos eficiente indexar alfanuméricos que números.

Intercalación: sus desarrolladores pueden crear la misma clave con diferentes intercalaciones en diferentes tablas (esto sucede), lo que lleva a usar constantemente los comandos "recopilar" cuando se unen a estas tablas en consultas y eso se vuelve viejo muy rápidamente.

Espacio: un SKU de nueve caracteres como el de David toma nueve bytes, pero un entero toma solo cuatro (2 para smallint, 1 para tinyint). Incluso un bigint toma solo 8 bytes.

Answer 4

Esta es una elección entre claves primarias sustitutas y naturales .

En mi humilde opinión siempre favorecen las claves primarias sustitutas. Las claves primarias no deberían tener significado porque ese significado puede cambiar. Incluso los nombres de países pueden cambiar y los países pueden existir y desaparecer, y mucho menos los productos. Definitivamente no se recomienda cambiar las claves primarias, lo que puede suceder con las claves naturales.

Más sobre las claves primarias de sustituto :

Así que las claves sustitutas ganan ¿verdad? Bueno, revisemos y veamos si alguna de las estafas de las claves naturales se aplica a las claves sustitutas:

• Con 1: Tamaño de clave principal: las claves sustitutas generalmente no tienen problemas con el tamaño del índice, ya que generalmente son una sola columna de tipo int. Eso es tan pequeño como se pone.
• Con 2: Tamaño de la clave externa: no tienen problemas con el tamaño de la clave externa o del índice externo por la misma razón que Con 1.
• Con 3: Asthetics - Bueno, es un ojo del tipo de espectador, pero ciertamente no implican escribir tanto código como con claves naturales compuestas.
• Con 4 y 5: Opcionalidad y aplicabilidad: las claves sustitutas no tienen problemas con personas o cosas que no desean o no pueden proporcionar los datos.
• Con 6: Unicidad: están 100% garantizados para ser únicos. Eso es un alivio.
• Contras 7: Privacidad: no tienen problemas de privacidad en caso de que una persona sin escrúpulos los obtenga.
• Con 8: Desnormalización accidental: no puede desnormalizar accidentalmente datos no comerciales.
• Con 9: Actualizaciones en cascada: las claves sustitutas no cambian, por lo que no se preocupa sobre cómo conectarlas en cascada en la actualización.
• Contras 10: velocidad de unión de Varchar: generalmente son int, por lo que generalmente son tan rápidas de unir como se puede obtener.

¿Y también hay claves sustitutas vs claves naturales para clave principal?

Answer 5

Si cada producto tiene un SKU y el SKU es único para cada producto, no veo por qué no querría usarlo para una posible clave principal.

Answer 6

Siempre se puede tomar un hash de la SKU que eliminaría los alfas. Tendrías que codificar para posibles colisiones (lo que debería ser muy raro), que es una complicación adicional.

Usaría el hash para rellenar la clave principal y facilitar la importación inicial, pero al usarla en dB siempre trátela como si fuera un número aleatorio. De esa manera, la clave principal perderá su significado (y tendrá todas las ventajas de una clave auto-incrementada) permitiendo flexibilidad en el futuro.

Answer 7

También me gustaría ir con una clave principal de auto-incremento. El impacto en el rendimiento de tener una clave primaria alfanumérica está ahí, aunque no me atrevo a nombrar ningún número. Sin embargo, si el rendimiento es importante en su aplicación, hay más razones para ir con la columna de clave principal de autoincremento.

Answer 8

Una clave sustituta (campo INT de incremento automático) identificará de forma única una fila en la tabla. Por otro lado, una clave natural única (productName) evitará que datos duplicados del producto ingresen a la tabla.

Con un campo de clave natural único, dos o más filas nunca pueden tener los mismos datos.

Con un campo de clave sustituta, las filas pueden ser únicas debido al campo INT de incremento automático, pero los datos en filas no serán únicos porque la clave sustituta no tiene relación con los datos.

Tomemos un ejemplo de una tabla de Usuario, el campo Clave natural de la tabla (nombre de usuario) evitará que el mismo usuario se registre dos veces, pero el campo INT de incremento automático (ID de usuario) no lo hará.

Answer 9

Ya que está tratando con datos de múltiples proveedores fuera de su control, yo usaría una clave sustituta. No querrá tener que rearchitect su diseño de base de datos un día cuando uno de ellos le envíe un duplicado.

Answer 10

Yo aconsejaría tener un entero "sin sentido" autoincrementado como clave principal. Si alguien tiene la idea de reorganizar las ID de productos, al menos su base de datos no tendrá problemas.