Duda con estructura de BBDD MongoDB

The-Guest

Buenas, estoy haciendo el TFG y al usar Mongo me ha surgido una duda a la hora de estructurar la BBDD. En un principio había pensado usarla como una BBDD SQL, pero me pregunto si habría alguna manera de aprovechar más el hecho de hacerla en Mongo (sin complicar mucho el hecho de anidar los elementos).


Las relaciones serían: una persona puede tener varias clases asignadas (en caso de ser profesor) y varios módulos. Los módulos pueden estar presentes en varias personas y sólo en una clase. Mencionar también que las clases me interesan tenerlas a modo de lista en la aplicación para poder asignárselas a distintos profesores y alumnos.

PhDfailer

Te estas liando con lo que es una mongodb. En una mongodb no hay relaciones como tal. Son colecciones de documentos y puedes meter un documento o alguno de sus atributos de una coleccion en otra sin especificar nada.

Para que una persona tenga varias clases, le metes un atrubuto de clases qur sea un array con id de clases. Los modulos pueden estar como te de la gana de la misma forma.

Para tener las clases en modo de lista solo tienes que hacer un query que te coja toda la colección.

1 1 respuesta
The-Guest

#2 Lo de las relaciones lo decía más bien por si había alguna tabla sobrante que se pudiese incrustar en forma de documento alguna de las otras y supusiese algún beneficio en cuanto a rendimiento (quizás sea prácticamente despreciable en comparación a los malabares que habría que hacer para recorrer sus datos). Sé que no existen como tal y que tampoco se generan tablas intermedias, simplemente se referencian mediante el id o un array de ids si son varios. Gracias por contestar!

GaaRa90

como te comenta PHDfailer, no te lies, lo mas habitual es meter el id de la otra coleccion.

Mongo es bueno consultas simples, donde peca es a la hora de realizar consultas agregadas(repasate las agregadas y proyecciones), no obstante no me he mirao bien cuales son tus necesidades exactamente, pero siendo un TFG, donde la database no va a ser grande, incluso plantear en el TFG, un unico documento tocho (siempre es mas recomendable) que tener que hacer agregadas consultando varias colecciones, si despues quiere discernir por entidades de dominio, entonces tira por los ids de la otra coleccion.

1 respuesta
S

Estas usando una base de datos no relacional como si fuera relacional, en este caso esas tres tablas serian una única tabla que contiene todas las propiedades de las tres.

1 respuesta
The-Guest

#4 #5 Meteré entonces todo dentro de una colección. Entiendo que para proyectos con mucha información si será necesario crear diferentes colecciones y referenciar sus valores mediante el id para no tener mucha información redundante y anidación de documentos que sean difíciles de recorrer. Gracias a ambos

bornex

El caso de uso de una base de datos basada en documentos no es el que estás haciendo.

Antes de usar mongo deberías de preguntarte cómo es tu esquema: estático? O dinámico? (schemaless). Por lo que parece parece más estático.

¿Cómo son las relaciones que van a tener los datos? Uno a muchos, muchos a muchos, muchos a uno? Piensa que mongo sólo va a soportar uno a mucho nada más. Tanto muchos a muchos como muchos a uno vas a tener que hacerlo tu a mano, acabarás haciendo joins a mano, y mil cosas más que son naturales en SQL.

Y ya ni hablar del mantenimiento, es un dolor de huevos: compatibilidad hacia atrás y hacia delante.

Edit: de hecho mongo es de las peores bases de datos noSQL que puedes usar.

1 respuesta
The-Guest

#7 Escogí Mongo por diferentes motivos: quería tener un proyecto en GitHub con noSQL y es la única noSQL que vi en el grado (no tenía tiempo como para ponerme a investigar otras opciones).

Me gustaría saber por qué la consideras tan mala opción. Un saludo y gracias

2 respuestas
Kaledros

#8 Por esto:

#1The-Guest:

Las relaciones

Si tienes relaciones no uses una NoSQL. Es algo fundamental, lo que indica que aún no tienes claros los conceptos básicos sobre bases de datos.

1 1 respuesta
bornex

#8 Ahora te pongo links y demás pero te cuento un par de cosas que te vas a comer con papas.

Mongo usa Optimistic Locking lo que significa que si no gestionas bien este tipo de error en transacciones paralelas vas a tener pérdida de datos. Vas a terminar implementando una lógica de retry que si bien no es complicada da para un par de ratos chulos.

Hace poco le añadieron transacciones, no se si dispones de niveles de aislamiento como las bases de datos SQL clásicas, pero vaya que esto es otra cosa que es un dolor de huevos, hay muchísimos casos de uso en aplicaciones donde vas a querer tener el "todo o nada" cuando hagas varias operaciones de base de datos.

Los Sistemas gestores de bases de datos como Postgres, MySQL etc... Cubren el 95% de los casos de uso normales de una aplicación, es cuando tienes casos de uso específicos cuando debes de usar una NoSQL.

Es decir, tu problema es el que te tiene que guiar hacia el NoSQL, no del revés.

De todas maneras esto es un TFG, supongo que en la carrera te habrán explicado todo esto de ACID y demás, así que no te doy más la chapa.

Por otro lado, si lo que quieres es aprender, "to palante".

Edit: de hecho con postgresql por ejemplo, vas a poder obtener el mismo resultado que un mongo, pero mil veces mejor. Soporta el tipo de datos JSON con el que vas tener "schemaless" sin tener que tener un mongo, incluso vas a poder indexar los campos del JSON.

1 respuesta
The-Guest

#9 Relaciones tiene que haber en una BBDD no? Por más que sea una sola colección habrá arrays de documentos o documentos anidados que ya indican relación entre los datos, otra cosa es que no soporten todas las relaciones y te toque hacer malabares al programar (igual que para insertar datos, porque se lo tragan todo), o esa es la idea que tengo yo (que es bastante poca como puedes comprobar).

#10 La escogí porque las SQL son las que más he usado durante el grado y las que más trilladas tengo (dentro de lo que puede saber un junior) y saber manejar un mínimo las noSQL (comprobar datos antes de insertarlos, consultas...) supongo que dará un extra respecto a alguien que no ha trabajado nunca antes con ellas.

2 respuestas
Kaledros
#11The-Guest:

Relaciones tiene que haber en una BBDD no?

Uf, no. Pero ni de coña.

PiPePiTo

#11 A ver, traducido a mundo relacional, en NoSQL almacenas datos normalizadísimos, de manera que tu select siempre va a ser de la misma colección, independientemente de los filtros que uses, que tienen que ser campos dentro de esa colección.

Es decir, lo que en tu SQL puede ser 3 tablas como Usuarios, pedidos, envios en Mongo lo tienes todo como una colección, (pedidos por ejemplo) y dentro tienes la propiedad usuario que te has traido de otro lado al hacer el insert y la de envio que rellenarás cuando se haga el envio lo que sea.

No haces un inner join entre colecciones para sacar cada entidad, entonces tu relación está ahí, dentro del objeto, pero para hacer un select nunca haces joins, porque entonces está perdiendo la gracia de ser un document db y pasa a ser una db relacional muy cara en comparación.

Yo siempre lo he usado para guardar datos que necesito de manera rápida pero nunca para que fuese la fuente de la verdad, es decir, la info salía de un SQL, se hacía polling con varios servicios a las tablas que tocase, se montaban los objetos con la información necesaria en cada colección y se insertaban con un time to live de 7 dias, (la info normalmente era del mismo día o 2 a lo sumo) porque una vez consumida la info se guardaba todo en su sitio en el SQL.

Esto quiere decir que para mandar un email en lugar de hacer un select de 4 tablas o las que sean para pillar el email, template, fecha de envio blablabla directamente pillaba el valor del collection que ya lo traia todo, cuando se enviaba se actualizaba ese valor y luego ya otro servicio por detrás lo sacaba del mongodb y lo guardaba en las correspondientes tablas del sql.

tremendo tochi me he marcado en un plis xD

Usuarios habituales