title: Best practice for scaling SQL queries on joins?
body: <p>I'm writing a REST api that works with SQL and am constantly finding myself in similar situations to this one, where I need to return lists of objects with nested lists inside each object by querying over table joins.</p>
  <p>Let's say I have a many-to-many relationship between Users and Groups. I have a User table and a Group table and a junction table UserGroup between them. Now I want to write a REST endpoint that returns a list of users, and for each user the groups that they are enrolled in. I want to return a json with a format like this:</p>
  <pre class="lang-json prettyprint-override"><code>[
      {
          &quot;username&quot;: &quot;test_user1&quot;,
          &lt;other attributes ...&gt;
          &quot;groups&quot;: [
              {
                  &quot;group_id&quot;: 2,
                  &lt;other attributes ...&gt;
              },
              {
                  &quot;group_id&quot;: 3,
                  &lt;other attributes ...&gt;
              }
          ]
      },
      {
          &quot;username&quot;: &quot;test_user2&quot;,
          &lt;other attributes ...&gt;
          &quot;groups&quot;: [
              {
                  &quot;group_id&quot;: 1,
                  &lt;other attributes ...&gt;
              },
              {
                  &quot;group_id&quot;: 2,
                  &lt;other attributes ...&gt;
              }
          ]
      },
      etc ...
  </code></pre>
  <p>There are two or three ways to query SQL for this that I can think of:</p>
  <ol>
  <li>Issue a variable number of SQL queries: Query for a list of Users, then loop over each user to query over the junction linkage to populate the groups list for each user. The number of SQL queries linearly increases with the number of users returned.</li>
  </ol>
  <p>example (using python flask_sqlalchemy / flask_restx):</p>
  <pre class="lang-py prettyprint-override"><code>users = db.session.query(User).filter( ... )
  for u in users:
      groups = db.session.query(Group).join(UserGroup, UserGroup.group_id == Group.id) \
          .filter(UserGroup.user.id == u.id)
  retobj = api.marshal([{**u.__dict__, 'groups': groups} for u in users], my_model)
  # Total number of queries: 1 + number of users in result
  </code></pre>
  <ol start="2">
  <li>Issue a constant number of SQL queries: This can be done by issuing one monolithic SQL query performing all joins with potentially lots of redundant data in the User's columns, or, often more preferably, a few separate SQL queries. For example, query for a list of Users, then query the Group table joining on GroupUsers, then manually group groups in server code.</li>
  </ol>
  <p>example code:</p>
  <pre class="lang-py prettyprint-override"><code>from collections import defaultdict
  users = db.session.query(User).filter( ... )
  uids = [u.id for u in users]
  groups = db.session.query(User.user_id, Group).join(UserGroup, UserGroup.group_id == Group.id) \
          .filter(UserGroup.user_id._in(uids))
  aggregate = defaultdict(list)
  for g in groups:
      aggregate[g.user_id].append(g[1].__dict__)
  retobj = api.marshal([{**u.__dict__, 'groups': aggregate[u.id]} for u in users], my_model)
  # Total number of queries: 2
  </code></pre>
  <ol start="3">
  <li>The third approach, with limited usefulness, is to use string_agg or a similar approach to force SQL to concatenate a grouping into one string column, then unpack the string into a list server-side, for example if all I want was the group number I could use string_agg and group_by to get back &quot;1,2&quot; in one query to the User table. But this is only useful if you don't need complex objects.</li>
  </ol>
  <p>I'm attracted to the second approach because I feel like it's more efficient and scalable because the number of SQL queries (which I have assumed is the main bottleneck for no particularly good reason) is constant, but it takes some more work on the server's side to filter all the groups into each user. But I thought part of the point of using SQL is to take advantage of its efficient sorting/filtering so you don't have to do it yourself.</p>
  <p>So my question is, am I right in thinking that it's a good idea to make the number of SQL queries constant at the expense of more server-side processing and dev time? Is it a waste of time to try to whittle down the number of unnecessary SQL queries? Will I regret it if I don't, when API is tested at scale? Is there a better way to solve this problem that I'm not aware of?</p>