Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I don't need your query language

antonz.org

Post reply on HN
Print view View original

281–290 of 304 posts

Re: I don't need your query language

#281

Post by 8note »

t8sr wrote: post #179
frognumber wrote: post #27

I'm working on a query language right now! Why not SQL? Lack of tooling for SQL. Yes, SQL lacks tooling. There's a ton of stuff to build a SQL client, obviously. However, on the other side: - I have no sane way to parse SQL - I have no sane way to comprehend SQL Writing a SQL query system would be many months of work. Tossing together a good-enough query language with standards like JSON or YAML means I can json.load…

This comment is full of hyperbole. Writing a precedence-climbing SQL parser should take a few days. I know because I've done it. I don't know where you're getting "months of work" - mine ended up being like 600 lines of Python. And I don't know what you mean by "no sane way to comprehend SQL" - I guess the millions of data people in the industry are just insane? Cobbling it together with YAML or JSON is a reasonable…

As far as "comprehend" goes, id think about getting typed responses to sql where I put in an arbitrary query and get a typed output.

Generally, I've only seen ORMs create the query from the object, rather than the object from the query

Re: I don't need your query language

#282

Post by lofaszvanitt »

nickpeterson wrote: post #72
jrumbut wrote: post #15

I think of SQL as one of the few good things we have in software development, so like the author I consider it best to try to do as much in SQL as possible. It's not too uncommon I run into code in other languages where I just don't understand what it does, or to write code myself that behaves in ways that surprise me. That almost never happens in SQL. Even a big hairball of a query just takes time to figure out (unl…

I tell new developers that SQL is one of those few things in our field you get to keep forever. That JavaScript framework that takes a year to understand will no longer be used in 7 years. SQL is going to be here forever and learning it is useful your whole career. Other common entries on this list of forever tools: regular expressions, emacs, bash/shell scripting, excel, probably more I’m forgetting. Devs always pus…

I tell new developers that SQL is one of those few things in our field you get to keep forever. --- I'm not so sure anymore. Look what is happening with css... every simple thing will be killed and replaced with something complex, so you could achieve less with much more effort.

Re: I don't need your query language

#283

Post by 8note »

smitty1e wrote: post #39
nalgeon wrote: post #6

Earlier quoted context omitted.

No. I'm talking about "SQL shaming" and about my preference for SQL over yet-another-query-language. I have absolutely nothing against EdgeDB or its creators. As far as I can tell, it's a great product.

The joy of SQL is that it's so high-level. Other responses note some (to me) esoteric enterprise use-cases for which SQL may not sufficiently describe exotic data vistas. Sure. But most of the "shaming" one encounters seems to be about advertising some sort of magic wand product more than pointing out a substantial woe in a system that has been prominent for a half century.

It is, and it isn't. Similar to prolog, you start high level, then have to bend over backwards making your high level description into an implementation aware low level description, by mashing the high level components together into the right spell to make the low level implementation go brr

Re: I don't need your query language

#284

Post by preseinger »

gemstones wrote: post #49
DaiPlusPlus wrote: post #18

SQL 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…

Yup, this right here. This aspect of SQL is overwhelmingly why I insist on ORMs, too. Any efficiency gains you get by having a senior dev write raw SQL for a complex query are immediately negated by a junior turning what an ORM would write as a single query into three DB calls. All because SQL insists on a flat result set you have to turn into a nested collection yourself, without an ORM doing it for you with eager l…

"raw sql" is table stakes, core competency for every software engineer

ORMs 100% always do it worse

Re: I don't need your query language

#285

Post by WuxiFingerHold »

mcdonje wrote: post #66
LunicLynx wrote: post #4

The 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.

I get around this when hand coding by doing a quick 'SELECT * FROM', adding my joins, then going back and filling in the fields using intellisense. Intellisense doesn't know what columns are available until the FROM clause is handled. To me, this is a slight annoyance with an easy workaround. If the SQL spec gets updated to allow switching the clauses around, I'll be pleased. But I'm not about to change languages ove…

Oh, that's a great idea. What editor/ui do you use? Since I've got divorced from Jetbrains I miss Datagrip ...

Re: I don't need your query language

#286

Post by netcraft »

mplanchard wrote: post #275
rbalicki wrote: post #223

Earlier quoted context omitted.

As someone who would like to use SQL to return a tree-like structure, how well does this scale (in terms of readability, performance, etc.) when the query is extremely large and nested? For example, if we are attempting to replace GraphQL with some sort of SQL. I'm super unfamiliar with this space, and would love to know whether it is a feasible/worthy goal to replace GraphQL queries with generated SQL.

Like with most performance questions, it depends. I see someone else said that it scaled well for sqlite. For postgres, it very much depends. Building a json object is much, much slower than selecting a row. Updating JSON objects involves building a new one, since you need to replace the entire object, so avoid building your schema in a way that requires updating JSON objects. (Experience is with postgres 14. To be f…

building a json object is slow compared to returning rows. but its far faster than multiple trips to the database to build a json object in the application layer.

Re: I don't need your query language

#287

Post by 1st1 »

tikhonj wrote: post #238

Having used (a lot) of Hive SQL, I absolutely do need your query language. SQL is fundamentally incapable of expressing any sort of abstraction, so non-trivial queries quickly become completely incomprehensible, unmaintainable and bug-prone. Learning a new language is a one-time, up-front cost. Dealing with an awkward, inexpressive query language that integrates poorly with my main language, my types or my interface…

Check out EdgeDB, you'll like it.

Re: I don't need your query language

#288

Post by zzzeek »

jrm4 wrote: post #253

I feel like this entire debate is strongly influenced, if not soon made obsolete and pointless, by the presence of the so called AI tools. Feels like there's a universe of difference between the experience of "carefully craft the query yourself" and "describe the query and let AI write the code for it."

oh let's just see that world where "AI" is "writing" the SQL queries and see how that goes.

LLMs work by hallucinating mashups of existing code examples stolen from webpages. Writing correct SQL for complex cases definitely needs real understanding, not just elaborate typeahead.

Re: I don't need your query language

#289

Post by throwaway2990 »

mattmanser wrote: post #104
tomnipotent wrote: post #95

Earlier quoted context omitted.

> which costs CPU Which costs very little CPU in 2023. > deserialised on the application server This is true regardless. The low-level libraries are still parsing the stream into meaningful in-memory structures. With JSON, the low-level library only has to parse a variable length string, then JSON decode. I'm unfamiliar with any language in 2023 that doesn't have incredibly fast and efficient JSON parsers. > bandwidt…

No, you can't use 'negigibly' worse as a defence. It's either better, or not. Your comment does not make it better, it's still worse. So it won't improve performance, but degrade it, even if it's negilible. So there's no reason to do it. Plus you've made a crazy SQL select instead of a normal one, which is harder to maintain. So it's worse performance and worse maintenance. i.e. don't do this, it's dumb, especially f…

> No, you can't use 'negigibly' worse as a defence

Absolutely you can when I can absolutely guarantee you that you’ve written worse performing queries in the past that caused more cpu issues than the overhead of working with JSONB.

Re: I don't need your query language

#290

Post by t8sr »

8note wrote: post #281
t8sr wrote: post #179

Earlier quoted context omitted.

This comment is full of hyperbole. Writing a precedence-climbing SQL parser should take a few days. I know because I've done it. I don't know where you're getting "months of work" - mine ended up being like 600 lines of Python. And I don't know what you mean by "no sane way to comprehend SQL" - I guess the millions of data people in the industry are just insane? Cobbling it together with YAML or JSON is a reasonable…

As far as "comprehend" goes, id think about getting typed responses to sql where I put in an arbitrary query and get a typed output. Generally, I've only seen ORMs create the query from the object, rather than the object from the query

I don’t understand the problem - is it that you don’t know the result type from just the query? (You need to consider the underlying schema)

Or are you talking about something different?

Post reply on HN