Question

In my limited experience in working with ORMs (so far LLBL Gen Pro and Entity Framework 4), I’ve noticed that inherently, queries return data for all columns. I know NHibernate is another popular ORM, and I’m not sure that this applies with it or not, but I would assume it does.

Of course, I know there are workarounds:

• Create a SQL view and create models and mappings on the view
• Use a stored procedure and create models and mappings on the result set returned

I know that adhering to certain practices can help mitigate this:

• Ensuring your row counts are reasonably limited when selecting data
• Ensuring your tables aren’t excessively wide (large number of columns and/or large data types)

So here are my questions:

1. Are the above practices sufficient, or should I still consider finding ways to limit the number of columns returned?

2. Are there other ways to limit returned columns other than the ones I listed above?

3. How do you typically approach this in your projects?

Thanks in advance.

UPDATE: This sort of stems from the notion that SELECT * is thought of as a bad practice. See this discussion.

Answer 1

One of the reasons to use an ORM of nearly any kind is to delay a lot of those lower-level concerns and focus on the business logic. As long as you keep your joins reasonable and your table widths sane, ORMs are designed to make it easy to get data in and out, and that requires having the entire row available.

Personally, I consider issues like this premature optimization until encountering a specific case that bogs down because of table width.