Cómo diseñar una tabla de productos para muchos tipos de productos donde cada producto tiene muchos parámetros

@StoneHeart

Me gustaría ir aquí con EAV y MVC todo el camino.

@ Bill Karvin

Estas son algunas de las desventajas de EAV:

No way to make a column mandatory (equivalent of NOT NULL).
No way to use SQL data types to validate entries.
No way to ensure that attribute names are spelled consistently.
No way to put a foreign key on the values of any given attribute, e.g.

Para una tabla de búsqueda.

Todas esas cosas que has mencionado aquí:

• validación de datos
• nombres de atributos validación de ortografía
• columnas/campos obligatorios
• manejo de la destrucción de atributos dependientes

En mi opinión no pertenecen en una base de datos en absoluto porque ninguna de las bases de datos son capaces de manejar esas interacciones y requisitos en un nivel adecuado como lo hace un lenguaje de programación de una aplicación.

En mi opinión usar una base de datos de esta manera es como usar una roca para martillar un clavo. Puedes hacerlo con una roca, pero ¿no se supone que debes usar un martillo que sea más preciso y específicamente diseñado para este tipo de actividad ?

Obtener resultados en un diseño tabular convencional es complejo y caro, porque para obtener atributos de varias filas que necesita hacer UNIRSE para cada atributo.

Este problema se puede resolver haciendo pocas consultas sobre datos parciales y procesándolos en un diseño tabular con su aplicación. Incluso si tiene 600 GB de datos de productos, puede procesarlos en lotes si necesita datos de cada fila de esta tabla.

Yendo más allá Si desea mejorar el rendimiento de las consultas puede seleccionar ciertas operaciones como por ejemplo, para informes o búsqueda de texto global y preparar para ellos tablas de índices que almacenarían los datos requeridos y se regenerarían periódicamente, digamos cada 30 minutos.

Ni siquiera necesita preocuparse por el costo del almacenamiento de datos adicional porque se vuelve más y más barato todos los días.

Si todavía le preocupa el rendimiento de las operaciones realizadas por la aplicación, siempre puede usar Erlang, C++, Go Language para preprocesar los datos y luego solo procesar los datos optimizados aún más en su aplicación principal.

Si utilizo Class Table Inheritance significa:

Una tabla para los Productos, almacenando atributos comunes a todos los tipos de productos. Luego, una tabla por tipo de producto, almacenando atributos específicos para ese tipo de producto. - Bill Karwin

Que me gusta lo mejor de las Sugerencias de Bill Karwin.. Puedo prever un inconveniente, que trataré de explicar cómo evitar que se convierta en un problema.

¿Qué plan de contingencia debo tener en su lugar cuando un atributo que es solo común a 1 tipo, entonces se convierte en común a 2, entonces 3, etc?

Por ejemplo: (esto es solo un ejemplo, no es mi problema real)

Si vendemos muebles, podríamos vender sillas, lámparas, sofás, Televisores, etc. El tipo de TV podría ser el único tipo que llevamos que tiene un consumo de energía. Así que pondría el atributo power_consumption en el tv_type_table. Pero entonces empezamos a llevar sistemas de cine en casa que también tienen una propiedad power_consumption. OK es solo otro producto, así que agregaré este campo a stereo_type_table también ya que eso es probablemente más fácil en este punto. Pero con el tiempo, a medida que empezamos a llevar más y más electrónica, nos damos cuenta de que power_consumption es lo suficientemente amplio como para que debería estar en el main_product_table. ¿Qué debo hacer ahora?

Añadir el campo a la main_product_table. Escriba un script para recorrer la electrónica y poner el valor correcto de cada type_table al main_product_table. Luego suelte esa columna de cada type_table.

Ahora si yo siempre estaba usando la misma clase GetProductData para interactuar con la base de datos para extraer el producto info; entonces, si cualquier cambio en el código ahora necesita refactorización, debería ser solo para esa Clase.

Puede tener una tabla de productos y una tabla ProductAdditionInfo separada con 3 columnas: ID de producto, nombre de información adicional, valor de información adicional. Si el color es utilizado por muchos pero no todos los tipos de Productos, podría ser una columna anulable en la tabla de productos, o simplemente ponerlo en ProductAdditionalInfo.

Este enfoque no es una técnica tradicional para una base de datos relacional, pero he visto que se usa mucho en la práctica. Puede ser flexible y tener un buen rendimiento.

Steve Yegge llama a esto el patrón de propiedades y escribió un largo post sobre su uso.