Diseño de database – productos de varias categorías con properties

Estoy diseñando un sistema de deviseio básico para un proveedor.
Tienen muchas categorías de productos diferentes.
Cada categoría de producto tiene muchas properties diferentes.

A – x1, x2, x3, a1, a2, a3;
B – x1, x2, x3, b1, b2, b3, b4;
C – x1, x2, x3, c1, c2;

Laptop - Make, Price, Quantity, Processor, OS, Hard drive, Memory, Video Card etc Monitor - Make, Price, Quantity, Size, ContrastRatio, Resolution etc Server - Make, Price, Quantity, Processor, OS, Memory, Netowrking etc 

Diseño1: diferentes tablas para cada categoría.
Diseño2: Tabla común, tabla de properties.

¿Cuál es el mejor enfoque?

Definitivamente no quiero multiplicar esquemas innecesariamente (regla de Occam, ya sabes). La forma estándar de organizar relaciones de muchos a muchos es simplemente una tabla intermedia:

 Products -------- ProductID Categories ---------- CategoryID ProductCategories ----------------- ProductID CategoryID 

Es fácil de consultar y una de las mejores prácticas de la industria.

Sin saber más sobre su dominio, me inclinaría a utilizar el layout 2. Esto limitará el número de tablas y hará que las consultas sobre las diferentes properties de múltiples categorías sean mucho más legibles y eficientes.

El Diseño 1 merecería la pena considerarlo si tiene un pequeño número de categorías que son estáticas y cada una tiene properties diferentes. Si este es el caso, aún puede usar el layout 2 creando una tabla de dictionary de properties. Aquí tendría una tabla que contiene los pares de key de propiedad / nombre de propiedad. Entonces su tabla de categorías puede contener una identificación de categoría, identificación de propiedad, columnas de valor de propiedad. Esto funciona bien si todas las properties tienen el mismo tipo de datos, pero pueden ser incómodas si no lo son.

Vaya con el Diseño 1, una tabla diferente para cada categoría.

El layout 2 va a ser un problema si los attributes no son todos del mismo tipo de datos. Si no, te obligará a almacenarlos todos como cadenas y escribir un montón de código de transmisión. Esto también evita la validation sencilla del tipo de datos de nivel DB.

Ir con la segunda opción requerirá una unión para cada consulta, ir con la primera opción hará que la consulta sea más difícil porque tendrá varias tablas y ahora tendrá que decidir cuál consultar. Preferiría la segunda opción porque a la larga el desarrollo de la aplicación es más simple (pero puedo ser flojo).

El layout habitual es una tabla común para las properties más comunes y luego una tabla secundaria para cada categoría con las properties especiales para esa categoría.

Alternativamente, puede usar la estructura de valores de la entidad, pero generalmente no se recomienda, ya que es difícil de consultar y no se escala bien.

Una cosa que tendrá que hacer y que la gente a menudo olvida es almacenar el precio al momento de la compra en el logging del artículo en deviseio (uno de los que consideraría las properties comunes). Si confía en un precio en una tabla de productos, se actualizará a medida que cambie el precio, pero para fines contables eso no es lo que se pagó por el artículo. ¡Esto puede ser muy malo cuando se audita o en time de impuestos!

"El layout 2 va a ser un problema si los attributes no son todos del mismo tipo de datos".

Si los attributes no son todos del mismo tipo de datos, entonces las properties que tales attributes representan no pueden ser comunes.