On Saturday, 10 January 2015 at 13:19:19 UTC, Martin Nowak wrote:
On 01/10/2015 01:52 PM, Jacob Carlborg wrote:
On 2015-01-10 13:36, Martin Nowak wrote:
The idea isn't bad, but the performance will suck. This is
generally
known as N+1 query, only that this is even worse, as each
field is
queried individually.
Since the "all" method was called I would assume all rows in
the person
table are fetched in one single query. Although I don't know
if that
will work if not the whole row should be loaded.
The issue is not with the rows returned, but the columns (or
object properties - which may map to multiple tables or be
derived in some other way). Which rows need to returned is
determined by some type of filtering mechanism, which is not an
issue because that (logically) has to be explicit. The issue is
determining which properties (for each "row") actually need to be
returned without the need to explicitly request them (the data is
already implicit within the user code itself).
Here is a sketch for an optimal solution. I'm actually
eagerly waiting
that someone finally implements it.
http://dpaste.dzfl.pl/cd375ac594cf
Martin, that is brilliant! It seemed like all the pieces where
there, I just couldn't put them together. I'm glad I'm not the
only one thinking about this.
I have never been able to find an ORM (in any language) that
comes close to working for us. We are currently looking into
switching off PHP and the front runner is C# because it's a safe
bet, we run Windows, and some people are sold on the concept of
Entity Framework. Entity is (or was) built in to the .NET so they
could theoretically do some neat tricks like compile query logic
at compilation, and infer what data is actually needed by the
program (the issue being discussed). Turns out they do query
caching, but that's about it.
I'm not sure I can sell the idea of D (this is a very small and
conservative group). I would also have to sell the idea of
writing an ORM which is certainly not on the roadmap, but this
will certainly help my argument.
Oh, we will also need a good SQL Server library which, to my
knowledge, D is lacking. This is going to be a hard sell...
-Dave
