The "Vietnam" article referenced in the post makes some very valid points about ORMs and their marriage to Relational data. When using Object Oriented Language

The "Vietnam" article referenced in the post makes some very valid points about ORMs and their marriage to Relational data. When using Object Oriented Languages, like C# / Java / C++ etc., the programmer is forced to represent data into objects. True, representing table and relations between tables as objects is difficult, but do OO programmers have any choice at all? Afterall, the issue is not a single table (a row can very well be represented in OO constructs), it's the relation between tables that causes headaches. Even when using languages like Python, I have to inevitable gather related pieces of data together, in a dict say, and it still feels like mapping related tables to objects. Another contention with the "vietnam" article is that the author assumes that OO programmers will want to use inheritance to model relations between tables. This seems outdated in my view. Composition is more suitable and powerful and is almost always used in ORMs, for ex Entity Framework. The original post also claims that ORMs tend to gravitate towards "select *" queries. This is true, but has many solutions. Many ORMs optimize queries based on required columns. But there is also another issue with this. Say you have a table with 100 columns, but are only querying 5 at a time, isn't it prudent to separate out those 5 columns into another table? Or perhaps create a view? If the use case demands just 5 columns, but the table has 100, isn't there a problem with the data modeling rather than the ORM?