3 ms·

The MongoDB document linked says "Referencing should be used to represent complex many-to-many relationships" ... "References are usually implemented by saving

The MongoDB document linked says "Referencing should be used to represent complex many-to-many relationships" ... "References are usually implemented by saving the _id field of one document in the related document as a reference. A second query is then executed by the application to return the referenced data." So... It's like a join, but with two queries instead of one, and you push the join data to the webserver, which brings us back to the start of this comment thread...

scarface74 9y ago
From your scenarios and what your asking to get from your data (yes I understand your problem domain, I wrote mobile software for field service workers in a previous life), you're not doing a lot of complex two way joins where you need to get all of the data from table A and match it to all of the data from table B. You're starting with a known entity like a terminal with references to other known entities. In your scenarios all your DB is doing is searching tables based on indexes and creating a data set in memory. If you did the same searches one table at a time starting from your known root - the terminal you are looking for and query individual tables based on foreign references, the only performance difference would be the slight overhead of multiple DB calls. You wouldn't even be getting unnecessary data back. Even if I were using a relational database, I would still separate out my different domains (drivers, terminals, stops, etc.) into different classes/microservices and join the different entities in memory. This would allow different developers, teams etc. to focus on separate business objects and would allow you to start off with a monolithic code base/app and separate the app out to microservice later without intertwined logic and to mix and match storage based on what makes sense. I never said always embed everything into one document. I said think through your aggregate roots to decide how to design your apps and your document model. I've designed this way for the last 10 years - 9 using RDMSs. I don't do complex 10 way joins for apps. I separate out business domain logically and let each module be responsible for its own domain and then have an overarching orchestrating class that combines the various objects when needed.
- nulagrithom 9y ago
  > I don't do complex 10 way joins for apps. That hits home. There's a lot of this in the legacy code base, and yeah, it's painful. Interesting approach. Thanks for the discussion. I'll have to ponder this a while.

scarface74 9y ago

From your scenarios and what your asking to get from your data (yes I understand your problem domain, I wrote mobile software for field service workers in a previous life), you're not doing a lot of complex two way joins where you need to get all of the data from table A and match it to all of the data from table B. You're starting with a known entity like a terminal with references to other known entities. In your scenarios all your DB is doing is searching tables based on indexes and creating a data set in memory. If you did the same searches one table at a time starting from your known root - the terminal you are looking for and query individual tables based on foreign references, the only performance difference would be the slight overhead of multiple DB calls. You wouldn't even be getting unnecessary data back. Even if I were using a relational database, I would still separate out my different domains (drivers, terminals, stops, etc.) into different classes/microservices and join the different entities in memory. This would allow different developers, teams etc. to focus on separate business objects and would allow you to start off with a monolithic code base/app and separate the app out to microservice later without intertwined logic and to mix and match storage based on what makes sense. I never said always embed everything into one document. I said think through your aggregate roots to decide how to design your apps and your document model. I've designed this way for the last 10 years - 9 using RDMSs. I don't do complex 10 way joins for apps. I separate out business domain logically and let each module be responsible for its own domain and then have an overarching orchestrating class that combines the various objects when needed.

nulagrithom 9y ago
> I don't do complex 10 way joins for apps. That hits home. There's a lot of this in the legacy code base, and yeah, it's painful. Interesting approach. Thanks for the discussion. I'll have to ponder this a while.