Question

Hola amigos.

Estoy diseñando un pequeño sistema de consulta y estoy detenido en el diseño de la base de datos, especialmente para tocar el tema de SKU's (Números de parte).

Resulta que el sistema de consulta manejará los números de parte internos de la compañía como llave primaria para búsqueda de los detalles de los mismos, pero a su vez, los números de parte que la compañía crea se los vende a sus proveedores que a su vez ellos asignan un numero de parte (SKU) diferente al mismo componente.

Es decir, sí la compañía fabrica el numero de parte "1234A" y se lo vende al cliente "Customer1", el cliente tiene su propio numero de parte "789B", pero también la compañía se lo vende al "Customer2", "Customer3" y "Customer4" y cada uno asigna su propio numero de parte (SKU) al componente fabricado por la compañía.

¿Como sugieren el diseño relacional de la BD para poner ligar la tabla donde se encuentran los detalles de la parte fabricada (Componente) con todos los clientes y a sus propios números de parte? La idea principal es buscar por SKU, no importando si es por el SKU de la compañía, o de cualquier cliente.

Les agradezco por adelantado.

Saludos desde México!

Comments

Hola,

el problema que planteás está claro y la respuesta de Carlos es correcta. Te escribo por una duda que me surje de tu planteo:

En qué momento se asigna el SKU a un producto de un cliente?

En qué momento se carga el SKU de un producto que un cliente vendió a otro cliente?

Me intrigan estas cuestiones operativas, que me llaman la atención tanto como que no se use siempre el mismo SKU para todos los procesos, que es lo habitual.

Saludos!

---

Hola Leonel.

El scope de la aplicación en un inicio es de solo consulta. Para esta fase no va a ser necesario crear algún modulo para cargar información nueva o actualizar la ya existente.

Por otro lado, nuestra compañia no asigna SKUs a los clientes, mas bien, los clientes asignan su propio SKU. Cuando nosotros vendemos nuestra parte "1234A" algunos cliente (por razones que desconozco) asigna un numero de parte diferente a ese componente.

Se que suena un poco extraño, pero la razón de este desarrollo es dar respuesta a los clientes cuando solicitan certificados de origen para tratados de libre comercio. Muchas veces los clientes nos piden el certificado de origen de componentes con su SKU interno y no con el de nuestra compañía. Ustedes dirán: ¿Y por que no solicitar al cliente que sus requerimientos sean con los SKUs de nosotros? Pero ya saben la respuesta mercadologica: El cliente siempre tiene (y tendrá la razón) jeje.

Saludos y gracias por su ayuda!

---

Gracias por la respuesta... sigo pensando que es una locura: en vez de pedirle al cliente que use y pida las cosas por su propio SKU, les van a tener que pedir un listado de productos en un formato específico para poder cargar al sistema los SKU que cada uno le haya asignado.

Me parece que es crear un problema más grande en vez de una solución!

Pero bueno, no nos toca decidir estas cosas, solo aconsejar y avisar sobre las consecuencias.

Saludos cordiales!

Answer 1

La primera solución que se me ocurre:

Tabla de productos primaria con SKU como clave primaria:

Productos
----------------------
SKU, Campo1, Campo2, ... CampoN

Tabla de clientes, la típica:

Clientes
----------------------
Codigo, Campo1, Campo2, ... CampoN

Tabla de relaciones de productos y clientes:

Clientes_productos
----------------------
SKU, Cliente_codigo, Cliente_SKU, Campo1, Campo2, ... CampoN

• SKU y Cliente_codigo serían claves foráneas (relacionado con sus respectivas
  tablas de origen).
• Además, la combinación de SKU y Cliente_codigo sería clave
  primaria de la tabla de relaciones para que cada cliente no tenga más
  de un registro.
• Cliente_SKU almacenaría el código que cada cliente le
  da a tu SKU.
• Puedes añadir más campos relativos a la relación (por
  ejemplo el precio de venta para ese cliente).

Si implantas esa solución a la hora de buscar tendrías que mirar todas las coincidencias que coincidan con las dos columnas de la tabla de relaciones (y traer campos de las otras tablas con JOIN). Varios ejemplos, en función de si quieres coincidencia exacta o no:

SELECT * FROM Clientes_productos WHERE 'Busqueda' IN (SKU, Cliente_SKU)

SELECT * FROM Clientes_productos WHERE SKU Like '%Busqueda%' OR Cliente_SKU Like '%Busqueda%'

Answer 2

Yo lo que haría es linkar en la tabla principal todas las demás tablas por el SKU respectivo, por ejemplo el artículo que has mostrado 1234A lo vende y el cliente1 le pone 789B de SKU, bien pues en la tabla de cliente1 789B tendrá una FK que referenciará a 1234A, si a su vez ese cliente vende 789B a otros tres clientes, en esos tres clientes tendremos el artículo 567C que referenciará a 789B que como a su vez referencia a 1234A no tiene pérdida. Es más, en las tablas de los clientes no tienes ni por qué guardar los datos del artículo que se podrían guardar una sóla vez en la tabla principal del artículo con su SKU original y todas sus características.

Así lo haría yo y es mi opinión.

SaludoS!