Clean OO-structure vs. SQL performance

IMO, I think you should just write another class that will encapsulate what you have. Does it always make sense for a blog to have an author? Does every author have a blog? Can an author have multiple blogs? Think about these issues, then design a class that will encapsulate this. Remember, typical database schemas are not OO... they are relational. Yes, they are close, but there are subtle differences.

So if an author can have multiple blogs, you can have a key to multivalued class of some sort (with the key based on author id) and you can initialize or load this class with one SQL call. Just some things to think about.

Unless you know for a fact that the inefficient sql operations will have no real impact, such as the number of redundant iterations or the rows affected will always be small (e.g. iterating an operation over the number of children in a family, which, short of very rare cases like the Duggars, can be relied on to be less than 10), I have always favored efficiency of the relational query over beauty of the OO code.

Although ugly OO code can make maintenance a pain, inefficient data access can bring a system to its knees, usually when you're on vacation or trying to sleep. And most of the time, you can find a good compromise that makes the most efficient SQL operations have a reasonably "objecty" interface. It may cost you a bit more time when it comes to refactoring or adding features if your object model isn't beautiful, but it is costing your customers time every single time they push that button (or money in terms of bigger hardware to run the app - never a good method of optimization), and the man hours spent using the app should far outstrip the man hours put into developing it (one would hope).

As far as your concerns about whether an interface will be needed (forcing you to figure out all possible consumption patterns), I have dealt with this by doing all my data modification via stored procedures, but allowing data access to go straight against the tables & views by giving all users select privileges only. This is a semi-controversial position, as many people would like to lock out all data access operations from downstream consumers in the name of ensuring that all sql being run is to their standards. But new ways of looking at the data are always coming up, and if you have to add a new stored proc, update your core class libraries and update your client code every time someone wants to implement a new feature, deployment and qualification can grow to be a real burden - far more than having to deal with an object model that doesn't fit a religious ideal. And it's a lot easier to implement a code inspection process that verifies that new select statements written by downstream consumers are kosher.

I'm a huge ORM advocate, and here's my weigh-in:

It's okay to trade an inperceptible amount of application performance for a ton of developer performance. Servers are extremely powerful these days and that extra iron gives us some new flexibility.

That said, if you do something silly that obliterates the user experience by bringing the server to its knees, that's no longer okay. If you had a million authors in your example, pulling them all down along with all of their fields and iterating through them would be unwise. If you had only 20 authors, then it's no big deal.

In the case of huge datasets and expensive batch operations, even as an ORM guy, I have to optimize and write special sprocs or SQL statements just for that case. And I have to be careful not to write my code in such a way that I hammer the database would it would be better to use a caching pattern where I pull down a large data set and then work off of that.

This is a big on-going debate, but to me it's just a matter of understanding that you can't solve every problem with a single tool.