¿Cuál es el esquema MySQL más elegante para productos, opciones y categorías?

Question

He trabajado con una docena de sistemas de plantillas (Zen Cart, Cube Cart, etc.). Cada uno de estos tiene su propia forma extraña de estructurar productos, opciones y categorías. Todas las características complementarias dan como resultado una situación de pila de tarjetas McGuyver que hace que trabajar con el código sea un arrastre total.

Hace seis años, construí mi propio motor de tienda web, que ha evolucionado a lo largo de los años y se ha convertido en su propia pila de tarjetas. Ahora estoy haciendo una revisión total del motor. Si bien nadie motor se adapte a todas las necesidades de tienda web, me preguntaba si el siguiente modelo tiene algún inconveniente, o si hay una mejor manera de crear una base de datos flexible, normalizada, no desagradable para el comercio:

Notas:
option_types = colores, tamaños, materiales
options = rojo, blanco, azul, S, M, L, algodón, spandex, cuero

Aparte de cosas básicas omitido a propósito (posición, activa, etc. .), alguien ve una manera de mejorar esto?

Answer 1

Aquí están mis notas/opiniones sobre esto. Te faltan cardinalidades, pero haré todo lo posible para adivinarlas.

• Categories está bien.

• Eliminar id de item_categories ya que no lo está usando. Cree una clave primaria compuesta en category_id y item_id.

asignando a cada registro un identificador único es más inteligente de muchas maneras: más rápido a las operaciones de búsqueda en un campo que en las dos, más seguro para eliminar, etc

Qué harías de búsqueda en esa identificación? Las consultas que ejecutará son: "Obtener todas las categorías para un artículo" y "Obtener todos los artículos para una categoría". No entiendo por qué sería más seguro eliminarlo. Sin embargo, yo diría que agregar un id puede ser un tanto peligroso de insertar ya que puede tener diferentes ID pero los mismos pares category_id y item_id. Usted tendrá que comprobar las limitaciones allí y asegurarse de que los pares son únicos (y no es que lo que se utilizan para PK?)

• items está bien ... (ver comentarios abajo)
• Quitar id de item_options (mismo caso que el anterior y ver comentarios más abajo)
• option_types está bien

Ahora, creo que la forma elementos y opciones están relacionados requerirá más pensamiento. Parece ser una relación de muchos a muchos. Como un artículo, como una camiseta puede tener muchos tamaños, tiene sentido decir que cada par de elementos y opciones debe tener un tamaño diferente. Pero qué sucede cuando, además del tamaño, también tiene un material diferente, como algodón y cuero. Deberá tener información sobre los pares de algodón-S, algodón-M, algodón-L y cuero-S, cuero-M y cuero-L. Esto tiene sentido ya que estoy bastante seguro de que todos tendrán un precio y peso diferentes. Pero ahora agreguemos 2 colores a nuestras camisetas. Deberá agregar un precio y un peso para cada una de las 12 combinaciones que tendremos ahora.

Sin mencionar que si un usuario desea ver el precio de un artículo, deberá elegir todas las opciones hasta que alcance el precio. No estoy seguro de cómo se debe hacer esto ya que no conozco los requisitos. Solo estoy lanzando una idea: podría aplicar precios y variaciones de peso sobre un precio base y un peso que serían parte del artículo.

Sólo algunos pensamientos no procesados ​​antes de ir a dormir:

• option_types podría ser algún tipo de jerarquía
• pensar cuidadosamente de cómo manejaría stock dado que el diseño. Tendrás 10 artículos para una camiseta negra ... pero ¿cuántos artículos tendrás para una camiseta de cuero negra? ¿Cómo se relaciona ese número con los 10 originales?

Answer 2

Tabla de opciones Agregar valor bajo nombre. es decir, Negro L Negro M Negro S Azul L Azul M Azul S etc. como un spin-off de la idea de Mosty.