Just as a test-bed, we’ll use a conversion to MongoDB of SQL Server’s classic practice database, AdventureWorks.
It is the database equivalent to cooking the meal beforehand in the kitchen rather than requiring each guest to cook their own meal at the table. I’m going to argue that, if you provide and maintain summary collections, known as aggregates or pre-aggregates, and you use a thread that is separate from the application in order to maintain them when the data in the tables change, then it doesn’t matter so much. Some people argue that document databases should de-normalise the data to get rid of the requirement for lookups. These require a lot of lookups, especially for reporting. Why bother with joins in a document database? As well as creating entirely new databases in MongoDB, we are beginning to see a lot more databases ported to MongoDB from the relational.
ROBO 3T QUERY BUILDER HOW TO
This article explains how to make such a MongoDB database perform reasonably when reporting historic and slowly-changing information. Data that is liable to change is always best stored in one place only. We can, of course, argue that collections of documents render joins unnecessary, but this is only true of relatively static, unchanging information. We can help Lookup along by providing an index that allows it to do an index nested loops join, but beyond that we have difficulties in getting dramatic improvements in the performance of any ‘JOIN’. It is far more suitable for enumerations where there is a limited range of alternatives. Lookup, the MongoDB equivalent to Joins, cannot yet do Merge joins or hash joins, so is never going to be fast in the current form. Even with indexes in place, some operations that involve aggregation are a lot slower than they are with relational databases: So it is when using ‘joins’ between collections.
MongoDB has a prodigious appetite for unstructured data and has its place in a Database Developer’s toolkit. Enjoying Joins in MongoDB - Simple Talk Skip to content
0 kommentar(er)
