¿Cómo diseñaríais la bd de una tienda de componentes de pc?

Si no vas a tener datos comunes o en este caso campos, lo mejor es tener una tabla que recoja tanto el nombre del campo como su valor.
Vas a tener una tabla de Componentes con su nombre, precio, categoría, identificador y más cosas
Luego tendrás una tabla extra vinculada a Componentes donde tengas: Identificador en esta nueva tabla, Identificador del componente, Nombre de la especificación, y otro campo que sea el valor de esta especificación.

Tabla Componentes
ID Nombre Categoría, Precio
1   Nvidia   1060   700€

Tabla características
ID ID_Componente Especificación Valor
1032     1        Velocidad       350mhz

Aunque esto no es eficiente para un gran número de productos, se usa más de cara a archivos de configuración para tener en orden ciertas opciones.

Al trabajar con productos categorizados y personalizados que suelen tener especificaciones comunes.
Me encaminaría por tablas para cada una de estas categorías y con su respectiva tabla adicional que recoja las especificaciones.

Puedes tener una variante de tener una tabla que recoja todos los productos y luego especificas para las especificaciones según categoría.

#4 Al fin y al cabo esta es parecido a lo que indica #3, a diferencia de que en vez tener una tabla con las características en sí, tendría todo en la tabla características.

Me gusta este diseño, no había pensado en hacerlo de esta forma y creo que es la mejor que puedo realizar en este caso. Concuerdo contigo en que lo más eficiente sería crear tablas por cada componente y especificaciones, pero con algo básico me sobra para un proyecto básico que quiero hacer, sin complicaciones.

Muchas gracias, me va a servir de gran ayuda!!!

#5 En un principio voy a utilizar MySQL y a pesar de que cabe como posibilidad hacerlo de esta forma, no creo que sea lo mejor en este caso y prefiero tener un diseño 'cerrado'.

#7 Si es para un trabajo puedo entenderlo, pero en producción no se recomienda hacer eso nunca. Básicamente más adelante, cuando madura el proyecto, empiezas a querer filtrar por X característica que tienes en esa columna guarra y, si la base de datos es muy grande, el rendimiento acaba siendo una mierda y acabar teniendo que refactorizar esa tabla.

Yo lo haría bien de primeras, una tabla por cada categoría (Id, NombreCategoria), productos (Id, NombreProducto, IdCategoria), características (Id, IdProducto, NombreCaracterística, ValorCaracterística).

#9 Por eso mismo, mi reply iba en torno a lo que él pregunta. Pensando en su caso en concreto, que metes en esa columna? características vas a querer trabajar con esos datos y relacionarlos, por lo tanto no sirve. No entiendo en que supuesto le va a servir la columna que propones

Voy a rizar más el rizo.

Una opción más que correcta, en la tabla que ha creado Vivora (Id, IdProducto, NombreCaracterística, ValorCaracterística)

Es tener una tabla extra que te recoja los "NombreCaracterística"
De esta manera, para características comunes, habría una tabla que las contuviera.

Porque cuando es mucha gente que escribe sobre la base de datos, se da el caso que escribas para un objeto como es la ram

• Memoria
• Memoria Interna
• Velocidad
• Velocidad de reloj
• Velocidad de memoria de reloj

De esta manera, si alguien escribe velocidad, va a buscar la que tengas establecida para esa característica. O si no existe, crear una nueva.
Permitiendo que no haya nombre de características duplicadas

Joder entre desu y juan el pobre se va a acabar haciendo panadero

Mae mia, cortita y al pie la pelota se;ores, le estais explicando fisica cuantica y aun esta entendiendo como sumar

Asi rapido, una tabla productos (Placa Base Saphire, Nvidia Gforce 2780x) y una tabla tipos (placa base, grafica)

productos tiene una columna type_id

Y ya a partir de este concepto hazlo todo lo dificil que quieras