Listas de Elementos en BBDD SQL

Meleagant

Estoy haciendo una aplicación que utiliza una base de datos SQL.

En dicha base de datos tengo una larga tabla de elementos, y los usuarios pueden combinar dichos elementos para crear subconjuntos de dicha tabla como listas propias.

Ejemplo de la tabla:

idElemento | nombre | etc...

0 | Casa | ...
1 | Coche | ...
2 | Arbol | ...
3 | Gato | ...

A la hora de guardar dichas listas en la base de datos me surge la duda de qué método será más óptimo.

La lógica de las bases de datos relacionales me dice que debería haber una tabla "Listas" con una estructura de este tipo:

Listas-Usuarios

idUsuario | idLista

284 | 1
573 | 2
284 | 3

Listas-Elementos

idLista | idElemento

1 | 3
1 | 0

Por ejemplo, para un usuario con una lista 1 que contiene los elementos "Casa" y "Gato".

Sin embargo, teniendo en cuenta que las listas serán mucho más largas, que cada usuario podrá tener varias y que los elementos son siempre los mismos, parece bastante recurrente. Además de esto, cada vez que quiera buscar una lista de un usuario tendría que coger todos los elementos uno por uno, cuando las listas son cerradas, siempre las voy a sacar completas (no me interesa extraer elementos separados de cada lista), etc.

¿Sería esta la mejor manera? Serializar la lista completa y guardarla como un único elemento me parece un poco burro y no sé si optimizaría el rendimiento, pero tener un montón de entradas separadas en una tabla tampoco me acaba de convencer.

¿Cómo lo véis? Supongo que estaré intentando reinventar la rueda y ya habrá una solución óptima a este problema, así que si alguien la conoce le ayudaría que despejase mis dudas.

kraneok

Yo creo que te estás respondiendo, es decir, ahí debe crearse una tabla N:N y ya está.
No deberías darle mas vueltas si en el diseño de bases de datos la relación debe de dar lo anteriormente dicho.
Intentar hacerlo de otra forma es complicarse demasiado y probablemente arriesgarse que la base de datos no funcione correctamente.

Ks1Qn0

Igual es un poco salvaje, pero si van a ser MUY largas yo lo haría en una sola table sumarizada:

idUsuario | idLista | idElemento

284 | 1 | 3

La implementación es menos directa pero te evitas joins, que para muchos datos pueden ser dolor computacional a la hora de acceder. Rizando más el rizo, pondría que el campo de elementos fuese algo así como un json, así de un sólo acceso te limpias una lista

1 respuesta
elkaoD

#3 estaba flipando porque creo que #1 lo había puesto así en su momento pero veo que ha editado #1 (o algo malo me pasa en la cabeza).

Yo también creo que es la mejor opción. PK (idUsuario, idLista) y a pastar.

1 respuesta
Meleagant

#4 Si si, lo había puesto así, sin pensarlo mucho pero en cuanto lo he visto lo he cambiado xD

Esa forma no me ahorra nada, lo único que haría sería aumentar la redundancia dado que una lista solo puede ser de un usuario.

Supongo que lo haré con una sola tabla que una elementos con listas.

También me planteo pasarme a MongoDB y hacer una subcolección de elementos, que puede ser más efectivo en este caso.

Meleagant

Bueno, para el que le pueda interesar o quiera opinar al respecto:

He hecho una revisión del esquema usando una BD relacional y usando MongoDB basada en Documentos.

La aplicación tiene 3 entidades: Usuario, Elemento y Lista, cada una de las cuales puede tener varios atributos.

En BD relacional, el esquema sería algo así:

En MongoDB el esquema queda de esta manera:

Visto lo cual, creo que voy a optar por un rediseño de la base de datos en MongoDB. Me parece bastante más intuitivo, simple y seguramente tenga un rendimiento superior, ya que no tendré que lanzar consultas sobre la totalidad de las listas cada vez que tenga que acceder a las listas de un usuario.

Se aceptan comentarios y sugerencias, y gracias a todos por vuestros comentarios anteriores :)

1 respuesta
elkaoD

#6 no sabes el jardín que es hacer una BD inherentemente relacional en Mongo. Ten cuidado si es tu caso.

1

Usuarios habituales

  • elkaoD
  • Meleagant
  • Ks1Qn0
  • kraneok