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

271–280 of 304 posts

Re: I don't need your query language

#271

Post by deely3 »

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…

Could you tell me what you want to accomplish by reimplementing query system? I really curious, because generally query systems used to query data from DB..

Re: I don't need your query language

#272

Post by mappu »

thomasmg wrote: post #197

We write programs with Python, Java, Rust, Javascript and so on. Yet we use a very different language, eg. SQL, to query and modify data. Why? Why don't we use eg. Python as well? SQL is different from other languages: it is declarative, meaning it doesn't dictate how to do it, but what the response should be. Maybe that's the reason? But if that's the case, why are declarative languages not more popular? SQL and oth…

SQLite somewhat works this way - the frontend compiles the query into bytecode instructions, that the data layer executes procedurally. It would be possible to expose that and write the bytecode directly (but it would take more effort to make it ergonomic.)

Re: I don't need your query language

#273

Post by x-shadowban »

drbawb wrote: post #109
nine_k wrote: post #63

Earlier quoted context omitted.

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…

Every time I have used an ORM I end up supplementing or replacing it with a "query DSL" like jOOQ, Linq, Arel, Ecto, diesel, etc. I seem to have the opposite problem of OP: I don't often find myself wanting to hydrate some complex object graph, what I really want is some small fraction of what constitutes "an object": "get me the distinct values of this column, sorted by another column", or "get me a list of user IDs…

Often we just want "totally adhoc result set, but constrained using some common where or join." We keep on with the orm, but it's basically a slow and complicated form of a view at this point

Re: I don't need your query language

#274

Post by iLoveOncall »

xboxnolifes wrote: post #260
iLoveOncall wrote: post #151

Earlier quoted context omitted.

You are missing what I said. I know that from the interpreter's standpoint, it doesn't matter which one is written first. What I meant is that as a human, if you have to think first of the columns you want to bring in, it will guide you towards the joins that you need and only those, rather than thinking "let me join all those tables because I need _some_ data from the entities inside". My point about "autocompletion…

Even if I know the exact query I want to write, your suggestion does nothing to improve autocomplete for typing it in.

Yes because that's not the main point of my comment. Disregard completely the part about autocomplete if you want.

I just added it as a separate point, to say "you can have autocomplete no matter the order in which you write your query"...

Re: I don't need your query language

#275

Post by mplanchard »

rbalicki wrote: post #223
erikpukinskis wrote: post #215

Earlier quoted context omitted.

> 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) For anyone (like me) who is not quite able to visualize this, here is an example: SELECT json_agg(trips) FROM ( SELECT json_agg( json_build_object( 'recorded_at', created_at, 'latitude', latitude, 'longitude', longitude ) ) as trips FROM data_tracks GROUP by t…

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 fair, performance was generally fine up until the 100s of millions of rows)

JSON query performance in postgres though is generally quite good. If you have static data, throwing it into a JSONB column with a jsonb_path_ops GIN index (or the default if you need the extra query flexibility) scales well up to billions of rows.

Re: I don't need your query language

#276

Post by mbStavola »

thomasmg wrote: post #197

We write programs with Python, Java, Rust, Javascript and so on. Yet we use a very different language, eg. SQL, to query and modify data. Why? Why don't we use eg. Python as well? SQL is different from other languages: it is declarative, meaning it doesn't dictate how to do it, but what the response should be. Maybe that's the reason? But if that's the case, why are declarative languages not more popular? SQL and oth…

I used to love writing SQL, but now I'm very much in the same camp as you. I don't ever want to write SQL, I want to write some straightforward code in my language of choice which allows me to interact with the underlying data structures of the DB; every lookup or aggregation I could do in SQL could definitely be written in a much more clear fashion if it was in Rust, JS, or Python.

I'm hoping that as WASM games momentum and WASI becomes an actual thing, some DB is going to pop up that does just that. I'd like to try myself one day.

Re: I don't need your query language

#278

Post by preseinger »

thomasmg wrote: post #197

We write programs with Python, Java, Rust, Javascript and so on. Yet we use a very different language, eg. SQL, to query and modify data. Why? Why don't we use eg. Python as well? SQL is different from other languages: it is declarative, meaning it doesn't dictate how to do it, but what the response should be. Maybe that's the reason? But if that's the case, why are declarative languages not more popular? SQL and oth…

querying relational data with set theory is pretty different to expressing imperative programs in a programming language

sql is not a programming language in the traditional sense, it's a mistake to try to think of it in those terms, or demand traditional programming language type stuff from it

Re: I don't need your query language

#279

Post by bavell »

magicalhippo wrote: post #105
mcdonje wrote: post #79

Earlier quoted context omitted.

DuckDB has some really nice syntax updates that I hope get added to the ISO spec, like GROUP BY ALL and GROUP BY aliases. I like their approach of adding thoughtful quality of life improvements instead of coming up with a new language. https://duckdb.org/2022/05/04/friendlier-sql.html

> GROUP BY aliases We're migrating from Sybase SQLAnywhere to MSSQL, and not being able to use aliases in WHERE, GROUP BY and ORDER BY is such a pain in the behind. Almost all our non-trivial queries have to be nested multiple levels due to this, which doesn't exactly help readability.

Ugh, I'll be having to do this same migration soon for one of my clients. Not looking forward to it. Good to know!

Re: I don't need your query language

#280

Post by preseinger »

bob1029 wrote: post #214
Jenk wrote: post #188

Earlier quoted context omitted.

The "domain" in the DSL of SQL is "relational data" not "your business domain"

What does this "relational data" (hopefully) represent?

it doesn't matter what the data represents, what matters is the structure of that data, and specifically (for SQL) that it is relational, rather than key-value or document-oriented or whatever

many business domains are well-modeled by relational data

some are not

Post reply on HN