![]() ![]() Hence, you would need to add the “0” manually in your application. However, in MongoDB there is no support for right outer joins. In Postgres, this requires a simple change to the query, namely adding a right outer join to the department table: select dname, sum(coalesce(salary * dedication_pct * In other words, she wishes to see the Candy department with a total salary of zero in addition to the other two departments. ![]() Let’s assume that the user actually wants to see all three departments with their total salaries. In contrast, in Postgres, the queries remain nearly unaltered and simple.Īll previous results are, however, a bit misleading, because the Candy department has no employees and does not appear in the join. Hence, on a change to the semantics of the join from 1:N to M:N, the application (or applications) must be significantly rewritten. It is natural to make the favored document the outer one, and we might choose Employee for that role. In MongoDB, there are two main ways to express a relationship, namely “embedded” and “reference.” Using the embedded approach one must decide which document is the “outer” and which is the “inner”. Note that there is a department (Candy) with no employees. In turn, departments have a dname, a floor and a budget. Here, employees have an ename, an age, a salary and are in a single department. Throughout this blog post, we will use the well-known example of employees and departments with the relational schema in Table 1. In Section 4 we show why MongoDB joins are brittle, and finally in Section 5 we consider join performance in both systems. We begin in Section 2 with MongoDB support for joins, then continue in Section 3 with the corresponding capabilities in Postgres. The conclusion is that MongoDB joins are very brittle (when things change, application programs must be extensively recoded), and often MongoDB offers very poor performance, relative to Postgres. In this blog post we review the JOIN capabilities in both MongoDB and Postgres. The first post covered “Schema Later Considered Harmful.” This is the second in a continuing series comparing MongoDB capabilities with those of Postgres. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |