5 ms·
> It's for querying records from a database. The application of the language does not make the language itself great. As we have seen with DSLs that often come
by randomdata 7y ago
> It's for querying records from a database.
The application of the language does not make the language itself great. As we have seen with DSLs that often come bundled with ORMs, there are other languages to query databases with (even if they ultimately compile to SQL), and I would argue that some of them do a lot better job than SQL does for providing a comfortable and cohesive environment for developers to write queries in.
In the imperative language space, we have one hundred and one different languages all trying to make things slightly more comfortable to developers. C, Go, and Rust can all be used to write the same kind of application, more or less, but that does not mean all of those languages are equally great. The same is true of declarative queries. Just because SQL is popular does not mean it is great.
> When you know how to write efficient SQL statements, ORM feels like having a hand tied behind your back.
ORMs and SQL are orthogonal concepts, really. There is no reason an ORM couldn't require you to hand-roll every single SQL statement. An ORM's concern is simply mapping the results of that query into the application's objects. That some ORM implementations also include functionality to build queries for you, often on top of the aforementioned DSLs, to make that mapping require less effort on the developer is, I would argue, largely a result of SQL being a bad language.
- linuxftw 7y agoWorking with relational databases might be difficult for those not acquainted with them. However, I think the SQL language as an interface primarily for relation databases is a great language. I think, invariably when you use ORM, you end up having query-specific object structures. For example [1]. You also might be passed objects with deferred fields [2]. This will be completely opaque to someone consuming the resulting object. You'll eventually run into this problem [3]. Solving the lazy load problem requires an understanding of how SQL works in the first place. And if you look at the solution in that example, it's an ORM-wrapped series of joins. From 3: > For good measure, we add a raiseload to throw an exception if we try to load anything that we didn’t load here. Who wants to live in this world? 1: https://stackoverflow.com/a/45905714/5573538 https://stackoverflow.com/a/45905714/5573538 2: https://docs.sqlalchemy.org/en/13/orm/loading_columns.html#column-deferral-api https://docs.sqlalchemy.org/en/13/orm/loading_columns.html#c... 3: https://engineering.shopspring.com/speed-up-with-eager-loading-in-sqlalchemy-87a176cfd7ad?gi=2e66321199fc https://engineering.shopspring.com/speed-up-with-eager-loadi...
- randomdata 7y ago> However, I think the SQL language as an interface primarily for relation databases is a great language. Which language(s) are you using as a point of comparison and why is SQL better than those other languages? SQL is no doubt better than nothing, but that is not in the spirit of our discussion.