It's funny how some devs are negative towards SQL but fiercely protective of other much more obscure tools from the 1970s, like unix utilities.
I don't need your query language
51–60 of 304 posts
Re: I don't need your query language
#52Also important: The behaviour of SQL is well understood, a new query language always introduces the risk of defects in the query language itself or developers making mistakes in an unfamiliar language.
Re: I don't need your query language
#53The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.
[deleted]
Re: I don't need your query language
#54I agree with many points, however, it depends on the abstraction that you need and the abstraction depends on the architecture you are adopting.
For example, if you are doing DDD and your repository implementation is about SQL, adding another layer of abstraction is not worth. But if your design is less sophisticated, or you are in an early stage of the project, you may find appealing to use that abstraction.
Re: I don't need your query language
#55"You can write SQL queries in lower case"
Re: I don't need your query language
#56The main issue with sql is, that it is the wrong way around, which eliminates all tooling support. You need to state what you want (select a, b, c) before you tell it from where to get it (from). And no tooling can predict that. So switching this, moving from and joins in front of select, might be everything needed to fix sql.
Almost exactly what I was going to say, then saw your comments. To me that the biggest problem. What I have been doing to workaround this is to just write select *, then finish the from join etc, go back and fix the result columns.
Re: I don't need your query language
#57I wonder if the author has tried CodeQL? One of the best query languages I've ever used, even if it is very domain-specific.
Re: I don't need your query language
#58I would love if sql would support a slight syntax change of accepting
From table select col;
as an optional alternative to
select col from table;
This would allow autocompleting col names in editors.
Other than that I quite like sql being the standard db query language.
Re: I don't need your query language
#59SQL does have a significant drawback w.r.t. how databases are used today (imo): a SELECT query can only return a single resultset of uniform tuples: if you want to query a database for hetereogenous types with differing multiplicity (i.e. an object-graph) then you either have to use multiple SELECT queries for each object-class - or use JOINs which will result in the Cartesian Explosion problem[1] which also results…
This is no longer true in database that have JSON support (which is most of them these days). You can aggregate the result of a subselect into a single column (the underling data doesn’t have to be stored as JSON, you can convert as part of the query)
That further increase the complexity of the queries, and then you start hitting weird corner-cases like postgres's difficulty (inability?) to convert a JSON array of JSON text elements to an array of text.
Re: I don't need your query language
#60I don’t really find the examples convincing. Like, I get that sql could maybe be written in a slightly less horrid way but I would prefer something a lot less horrid. I think I’m much more motivated by analytics queries than the kinds of thing in this example though. I find sql is poorly suited in this case because it is verbose and written backwards, and often requires many layers of subqueries. That said, one can u…
I think the problem here is with the query, not the language. You can immediately improve its maintainability and readability by using CTEs.