[gregjor]

Nothing you wrote has anything to do with ORMs, the actual point of this thread.

The shortcomings of SQL with respect to a pure relational model are well-known. For all practical purposes we have SQL. Almost everyone using a popular relational database engine — those that might have ORM support — uses SQL. The history of SQL and niche alternatives, while interesting, don’t have anything to do with using an ORM vs writing SQL.

I’m not confused about relational vs SQL. I just didn’t think the pedantry would add to the discussion.

Pointing out that SQL doesn’t implement the relational model correctly seems like pointing out that C++ doesn’t implement object oriented programming as Alan Kay defined it. True, but C++ got a lot of adoption and Smalltalk did not. Pointing out the OO shortcomings of C++ don’t help with using the language.

[randomdata]

> Nothing you wrote has anything to do with ORMs, the actual point of this thread.

Incorrect again. ORMs[1] are within the set of compile-to-SQL languages. They were very much spoken to. They are also not magic, just other languages that ultimately express the exact same thing (and have to, since SQL is the compiler target!). But, notably, support composition –– Which means that SQL can support composition, and it would be quite relevant for it to.

Furthermore, you remain confused as the whole reason we're talking about composition in the first place is because it is the reason why people are reaching for ORMs[1]. If SQL supported composition, they wouldn't need to. They could use SQL itself, happily. It is not some kind of general aversion to SQL. The problem is that the SQL language lacks functionality sorrily needed for real-world use, so people feel a strong need to reach for a better language that does provide.

Which is unfortunate, as using SQL itself directly without obscuring behind another language brings many benefits. But until it adds native composition support, you're in for a world of hurt in any kind of practical setting where there is more than one or two queries.

> Pointing out that SQL doesn’t implement the relational model correctly

It is not that it doesn't implement the relational model correctly. It doesn't try to implement the relational model at all. It chooses the tablational model instead. Which is fine. Arguably tablational is better than relational, so to call it relational is nonsensical and perhaps even a little demeaning. What leads you to such nonsense after 40+ years of exposure?

[1] Yes, technically the discussion has been about what are more normally called query builders, not ORM. If you really want to be pedantic, ORM is only concerned with translation between collection of sets and trees and has nothing to do with query expression, but this isn't about pedantry, it's about your poor understanding of SQL and how that has lead you to incorrect conclusions about composition.

[gregjor]

An opportunity to engage in a useful discussion derailed by ad hominem and conflating things.

SQL and the relational model (two different things) predate OOP and the need for ORMs (object-relational mappers) by one to two decades. It was the widespread adoption of Java — everything an object — in the mid-1990s that led to ORMs, at a time when various commercial “relational” databases already dominated data management. Microsoft’s Active Record and then Ruby/Rails, among others, perpetuated the use of ORMs. Most programmers who entered the field after 2000 learned ORMs and their associated query builders before learning SQL or relational database concepts, if they ever learned those things at all.

ORMs can make some things simpler, including composing queries, but as you noted that means SQL can do the same thing. Some more recent additions to SQL, such as CTEs, and features such as named views and subqueries that ORMs discourage, make SQL more composable. If we could write in predicate calculus we wouldn’t have to deal with SQL’s shortcomings, but that battle got lost in the 1970s and now we have decades and billions of lines of SQL (most of it not generated by ORMs) that won’t go away.

Going back to my original point, way up this thread… PHP and Go, specifically, do not need add-in ORMs because the languages have built in support for mapping query results to native objects/structs. If someone uses a query builder with those languages most likely they do so out of habit, or because they can’t or don’t want to write SQL. But PHP and Go do not need an ORM or query builder, just like they don’t need add-on HTML templating.