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

smarquezp

Buenas tardes!!!

Para el proyecto final estoy montando una tienda de componentes de PC y tengo una duda a la hora de realizar la base de datos.
¿Cómo diseñaríais vosotros esta base de datos en cuanto a los componentes?

En un principio pues tendré los típicos componentes de procesadores, tarjetas gráficas, discos duros...
Tengo en mente dos formas:

  • Crear una tabla por cada uno de los componentes: tabla 'procesadores', tabla 'tarjetas_graficas', tabla 'discos_duros'...
  • Crear una tabla con los nombres de componentes y una tabla 'componentes' que tenga todos.

La segunda forma me parece más limpia, pero en el caso de que quiera indicar todas las características por cada uno de los componentes, ésta no me sirve ya que no todos los componentes tienen las mismas.

Otra opción sería indicar cierto número de características principales (igual indicar 4 o 5, y en la base de datos tener 4 o 5 columnas con 'caracteristica1', 'caracteristica2'...) y poner un enlace a la página oficial (sería algo bastante cutre pero no quiero que me lleve tanto tiempo), que es la opción que había barajado y la que más tiempo me va a ahorrar.

¿Qué me recomiendan ustedes? Muchas gracias!!!

E

La segunda

Soltrac

Ni la 1 ni la 2.

Tabla componentes:

  • Nombre componente

Tabla características

  • Nombre característica

Tabla componentes-características

  • Id componente
  • Id característica
9 1 respuesta
B

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.

3 1 respuesta
cabron
#1smarquezp:

La segunda forma me parece más limpia, pero en el caso de que quiera indicar todas las características por cada uno de los componentes, ésta no me sirve ya que no todos los componentes tienen las mismas.

no sé que base de datos piensas usar, pero mysql y pgsql que son las más comunes soportan columnas de datos no estructurados donde puedes meter lo que quieras a piñon como si fuese un mongodb.

Es lo típico que si lo abusas acabas haciendo una aberración, pero es perfectamente valido para ciertos casos.

1 1 respuesta
smarquezp

#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'.

1 respuesta
cabron

#6

si vas a usar alguno de esos datos en alguna query, (ej se puede buscar/filtrar por características) no tiene ningún sentido hacerlo así, pero datos que solo sean como información y simplemente los vas a mostrar como parte del producto, te sale mucho mejor tener una columna donde meter todo lo que quieras que no hacer una columna por cada dato, de hecho precisamente este tipo de columna sirve para eso.

1 1 respuesta
vivora

#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).

1 2 respuestas
cabron

#8

no voy a desviar la discusión a algo que no tiene nada que ver en un hilo de una persona que ha pedido ayuda para hacer una cosa, pero vamos, que ese tipo de columna es totalmente usable de forma real en producción, simplemente tienes que entender por que se le llaman 'datos no estructurados' y de ahí saber que puedes y que no puedes hacer con ellos.

Como ya he dicho en el otro post, si planeas filtrar por ellos no tiene sentido una columna de este tipo

1 respuesta
vivora

#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

1 respuesta
richmonde

#8 Todo tiene sus pros y sus contras. Piensa que las características no siempre pueden ser numéricos. Todo depende de su uso final.

Precisamente, las BBDD columnares o NoSQL tienen la ventaja de poder hacer eso mismo, poner tantas columnas como te dé la gana, ya que a nivel de búsqueda, no indexa por valores de fila, sino de columna.

Volviendo al main topic del OP, todo depende para que sea el proyecto, que asignatura sea, y que finalidad tenga. Si en un campo añade características, posteriormente se puede tratar con split_part o regex.

Ahora bien, la forma más limpia, fácil de consultar y recomendada, es como te han dicho arriba.

ej:

Tabla Producto
idProducto, familiaProducto, nombreProducto, marcaProducto, nombreProductoRetail,...
10001, Nvidia RTX,  RTX 3080 Ti, MSI, MSI RTX 3080 Ti Ventus 3X OC
...
Tabla Caracteristicas
id_producto, id_caracteristica, nombre_caracteristica, tipo_caracteristica, version_caracteristica, valor
10001, 1, Memoria,  GDDR6X, null, 12000
10001, 2, RTX Features,  DLSS, 2.0, 1
...

Y ya si te lo quieres currar, pones historico de precios

id_producto, precio_pvp, precio_retail, fecha_inicio, fecha_fin, dto
10001, 1099€, 1499€, 2021-06-01, 2021-06-02, null
10001, 1099€, 1899€, 2021-06-02, null, null
...
1
B

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

1 respuesta
varuk

#12 Venía a decir lo mismo. Es mejor establecer los "estándares" de nombres y referenciar a eso.
Igual que hacer lo mismo en otra tabla con los nombres de Fabricantes, por ejemplo. Para que en unos no sea "Intel" y en otros "Intel Corporation" o cosas así... y simplemente en la tabla principal de características referencias a esas tablas donde se guarda los nombres "estándar", donde tienes que coger de ahí y no tienes otra opción (y si hubiera que editar un nombre de característica o fabricante... o añadir, etc. pues es mejor).

Además, haciéndolo así desacoplas más el diseño.

cabron

#10

pues lo pone en el post #7 al que ya has contestado así que entiendo que lo habrás leído

no tengo ni idea de que va a recoger en su base de datos ni que filtros va a meter así que simplemente le he dado la información de como puede usarlo, datos por los que vaya a filtrar no, datos adicionales que no sean iguales en cada producto y que vaya a mostrar junto con el producto sí

smarquezp

Pues creo que finalmente la opción más complicada al final, va a ser la más sencilla a la hora de implementar.

Creo que voy a hacer esto que decís y así será más eficiente a la hora de hacer filtros y tal.

Es decir, crear tablas con los "nombres" para que sean fijos y después las tablas que se relacionan. Mañana en un momento la diseñare y paso por aquí el modelo ER a ver que os parece.

Muchas gracias a todos por las respuestas, me habéis abierto los ojos!!!

desu

Otro punto de vista.

Plantealo desde el punto de vista de un dise;o de sistema, como se van a consumir estos datos? que campos tendras, cuantos kb sera una fila? cuantas entidades esperas tener, numero de entidades * X kb = tama;o que requerirás. como de volátiles serán estos datos, como incrementaran en el tiempo, cuantos componentes esperas a;adir por a;o. cuantos gb moveras por mes y cuanto creceras?

a quien cojones le importa tener 2 o 3 tablas optimizadas para hacer filtros entre las entidades si al final vas a tener 1M de entidades que te caben en una tabla y la puedes meter en memoria................ Tratar de tener un esquema de db desde el principio y teorizar sobre que queries escribirás y que sean rápidas es una bobada. No puedes predecir los casos de uso.

Tu pregunta esta mal planteada porque falta contexto, piensa en el contexto y resuelvelo, luego considera el crecimiento a futuro que problemas tendras y como los resoldras.

Tardas menos en hacer una elt en batch y re hacer las tablas a los 2 a;os (10 minutos de computo en cualquier cpu de mierda) que no los costes de mantener una db de mierda llena de incoherencias.

yo te recomiendo que hagas el peor dise;o que se te ocurra y lo implementes, haz una puta mierda de base de datos relacional, algo que de puta pena. metele 1M de rows con sus relaciones y luego tira queries complejas. mira los tiempos de query cuanto son... midelos. luego arregla la db y vuelve a tirar las queries. la verdad,, 1M de rows que tipo de queries tienen sentido? cuantas entidades relacionadas y cuantas rows? cuanto crees que tardara? cualquier chapuza de 500ms ya es mejor que mucha mierda en produccion que hacen pajeets sin cabeza... haz la mierda y luego arreglalo para tener <50ms...

luego te vendra tu jefe te dira que quieren hacer analisis y tendras que meterle una db orientada a columnas... el desarrollo es asi tete.

en fin esto si quieres aprender, si no quieres no lo hagas. yo estoy cansado de gente hablando de relaciones en db y de como dise;arlas sin haber tirado un benchmark en su puta vida ni saber como funciona un indice. hijo de puta que tienes 50k filas que se iteran en un bucle dejate de chorradas. XD

JuAn4k4

¿No sería mejor tener una bd de datos y otra cosa Royo elasticsearch para buscar?
Faceted search te permite tener props no estructuradas por las que puedes filtrar. Por ejemplo: memorySize=256 (MB)

En todo caso yo haría por propKey más que por propId. (Tus props van a estar hardcodeadas imagino).

isvidal

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

4 1 respuesta
JuAn4k4

#18 Con elasticsearch lo haces esto es dos patadas y es mejor tenerlo no estructurado porque tus props de cada componente van a cambiar.

Ejemplo:

Product Name=GeForceX537
ProductCode=A746C381B0
Kind=GraphicCard
Mem=2Gb
CacheSize=4Mb
SecondLevelCache=8Mb
Brand=GeForce
Price=253.45€

Algunas props serán fijas, pero te da igual, meter las todas como props en el índice y así, en una búsqueda por facets, te devuelve todos los props que salen y todos los valores posibles, ya busques tarjetas gráficas nuevas (con más props seguramente) o más viejas.

Otra cosa es luego ya como pintas cada entidad, para lo que vienen bien props fijas en la Bd "componente" Como product name/code/brand/description/price etc..

Me parece mucho más sencillo hacerlo así, tanto para el código como para el usuario.

Kind marca las props disponibles pero siempre puedes crear ad-hoc nuevas, sin limites, y salen para buscar.

14 días después
B

.

Usuarios habituales