#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
