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

61–70 of 304 posts

Re: I don't need your query language

#61

Post by wryanzimmerman »

danielheath wrote: post #19
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.

This is also my primary issue with vi. d3w (`d`elete `3 w`ords) cannot be highlighted / indicated in any way ahead of time. If the motion specifier came first, it could be.

If you want to highlight something, use `v` for "visual" mode

Re: I don't need your query language

#62

Post by [deleted] »

nicoburns wrote: post #43
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…

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)

[deleted]

Re: I don't need your query language

#63

Post by nine_k »

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…

From my experience, ORMs in hands of junior.developers who happen to not yet know SQL are a disaster. However hard the ORMs may try, the code ends up making a ton of small queries instead of one efficient query, and fetching a ton of unused columns. The developers then end up doing joins manually in application code, some distance further from the place of the original queries.

ORMs also tend to sneak "live" objects into unexpected places, triggering surprise DB accesses.

Not that ORMs are completely useless. We just need to stop pretending that there can be a smooth and performant automatic mapping between relational tables living in a DBMS and Business Objects living in some idealized world without storage limitations, where any connection between them is like following a pointer in RAM.

Most ORMs provide tools to write composable, reusable queries and parts thereof. These are the best parts.

Re: I don't need your query language

#64

Post by ledgerdev »

tester756 wrote: post #9
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.

C#'s LINQ (query syntax, not methods) got it right var result = from s in stringList where s.Contains("Tutorials") select s;

I recall Anders saying on some podcast they did that so they could provide auto-complete. Funny thing is that I used it for a couple years, but almost never use the linq syntax any more, and not sure why.

Re: I don't need your query language

#66

Post by mcdonje »

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 over it.

Re: I don't need your query language

#67

Post by wryanzimmerman »

Olreich wrote: post #40
danielheath wrote: post #19

Earlier quoted context omitted.

This is also my primary issue with vi. d3w (`d`elete `3 w`ords) cannot be highlighted / indicated in any way ahead of time. If the motion specifier came first, it could be.

`3w` is a command all its own. There’s an implicit move command baked in. Moving gets pretty clunky if you don’t have first order movement (adding a specifier or something to clear selection). You can mimic this by mapping a single button to and disabling all movement commands in normal mode. It’s rough, but may be learnable. I think something that might work better is adding a “commit” signal to operations. So you t…

If you use visual mode, you can do `v3w` to highlight three words, and then you can manipulate that selection before you do something with it, like `d` for delete.

You can also use that with ex commands, like if you do `vap:s/foo/bar/g` you will replace `foo` with `bar` only within the block of code you visually highlighted with `ap` (which I remember as “a paragraph).

So if you want “delete three words”, do `d3w`. If you want “highlight three words” do `v3w` and then issue another command like `d` to do something with what you highlighted.

Re: I don't need your query language

#68

Post by tomnipotent »

nicoburns wrote: post #43
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…

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)

Absolutely. JSON serialization is so well optimized in most RDBMS vendors now it puts very little additional CPU work on the database, and duplicating data in the output for large graph-based results is a small price to pay to breaking out of set-based constraints.

Re: I don't need your query language

#69

Post by masklinn »

hosteur wrote: post #58

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

That only fixes trivial selects. But you still have issues with e.g. GROUP BY, especially since the dependency is circular:

- barring extensions you can only select grouping expressions or aggregates

- but instead of repeating grouping expressions you can refer to a select expression (by index, some databases also allow the alias)

The "spec" order of evaluation for queries is WITH, FROM, WHERE, GROUP BY, HAVING, SELECT, DISTINCT, merge, ORDER BY, LIMIT. Although databases might decide to move SELECT after ORDER BY and LIMIT if they can, in order to avoid unnecessary evaluations.

Re: I don't need your query language

#70

Post by dewey »

ayhanfuat wrote: post #17
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.

All your example queries and quotations are from the EdgeDB landing page. Even if you are talking about "SQL shaming" you are very specifically talking about EdgeDB's SQL shaming.

You are missing the point, there's a reason why they don't name the database or link to it. It's a general behaviour that comes up with many new data stores or tools where you can query data. You could replace the images and examples with a different database that does something similar and the point would still stand.
Post reply on HN