News for hackers. Stuff that matters.
Re:How not to structure database-backed web apps: performanc... by Terr_ on Thursday June 28, 2018 @02:50PM (#17419460)
I imagine all of the non-toy ones would support joins for getting raw tabular data or for restricting what single kind of item (e.g. "Customer") you're pulling out.

Where it might get trickier is when you have something like a Customer-Region-Vendor join, and you actually want it to go ahead and create objects for the all of the Customers and Regions and Vendors whose data was pulled out of that one select.

Re:How not to structure database-backed web apps: performanc... by olavk on Thursday June 28, 2018 @03:31PM (#17419778)
In NHibernate and Entity Framework you just say .Include("Region").Include("Vendor") to eagerly load the associated entities. I imagine other ORM's have similar facilities.
Re:How not to structure database-backed web apps: performanc... by ht85 on Thursday June 28, 2018 @03:23PM (#17419730)
It is actually not that bad if instead of a single query, you do one query per table.

It even offsets some of the burden to the app, which is generally easier to scale than the database.

The idea is that you query the "root" table, loop over the results and build an array of IDs, then do additional queries to the other tables with a "where whatever_id IN (...)".

Re:How not to structure database-backed web apps: performanc... by Terr_ on Thursday June 28, 2018 @05:10PM (#17420508)
My understanding is that a lot of SQL drivers support compressing the data anyway, so that the server (and client) avoid duplicating the data over and over just to fill the rectangular result.