Hacker News Reader

Comment by mumblemumble | Hacker News Reader

This seems more useful if re-framed as "Why pulling data you won't use is bad for performance."

SELECT * seems like a strawman to me. I don't often see it in the wild anymore. But pulling more columns than you need is extremely common; it happens in every codebase I've ever seen. I habitually do it myself. More-or-less every time I choose to re-use a single function for retrieving data in several places. Because then the function needs to get the union of all the columns that all the callers need.

Which may be a reasonable trade-off. There's almost always a need to strike a balance between maintainability and performance. But it's also nice to have occasional reminders to re-assess what you've been doing. This particular practice tends to have a particularly high cost, and one that, depending on how you configure your environments, may be much larger in production than it is in development or CI.

View on HN

It can be extended upon.. I see a lot of ORM based solutions that pull a full record just to check a single property sometimes. E.g.:

    var user = repository.GetUserById(userId);
    return user.IsDisabled;

That's not even a facetious example, I have seen it multiple times. In some cases that query is pulling multiple columns, and a few joins.. just to pull a single bit value.

I see that, too. But I don't think it's fair to blame on ORM. I also see it happening in non-ORM code that uses the repository pattern, for example.

For example, there's nothing about the code example you give that strictly implies the use of an ORM, just the use of some sort of layered design.

I didn't meant to blame ORM, only highlight the (mis)use of them in this type of scenario - but yes, you are correct. It is an abuse of the repository - ORM or other. :)

Laravel Eloquent permits sparse loading of a model; but the way ORM is used in general, this might be a bug factory. Nevertheless I do use the technique where the objects exist only within the scope of a given subroutine.

This is not necessarally terrible in some scenarios: namely, when the repository caches enties for the duration of the unit of work, and the user in question is used elsewhere in the request (or at least is used elsewhere in the common case).

In that scenario, this can be strictly more efficient than doing a specialized query here, and a more general fetch of the user later, because it becomes just one sql command instead of two.

Obviously though there are ORMs that don't offer such caching, or cases where the value will not be used again elsewhere in the request, and in those cases this is clearly undesirable. It is generally quicker and easier to do this than adding a new custom method to the repository to get exactly the desired data which is why it remains common even in those scenarios.

On the other hand, if the user object was already recently used somewhere else it will be cached and this code will produce no database/network traffic at all.

Reply on news.ycombinator.com