Live data from Hacker News

SQLite: Past, Present, and Future

vldb.org

91–100 of 147 posts

Re: SQLite: Past, Present, and Future

#91
post #90

After seeing one diagram: Why the hack are we still talking to databases with SQL strings and not directly specifying the Query-AST? Admins, sure (a fancy UI could help there as well) but why in our code?

Can you give an example of what you mean, and what we'd gain from it?

Re: SQLite: Past, Present, and Future

#93
post #90

After seeing one diagram: Why the hack are we still talking to databases with SQL strings and not directly specifying the Query-AST? Admins, sure (a fancy UI could help there as well) but why in our code?

Can you give an example of what you mean, and what we'd gain from it?

When you're accessing a SQLite database in code you have to generate a query string. Parameters ameliorate that somewhat, but in many cases you still have to regenerate a new string for each new query. It's inefficient to translate your query into a string only to have it parsed back into something structured by SQLite.

Re: SQLite: Past, Present, and Future

#94
post #90

After seeing one diagram: Why the hack are we still talking to databases with SQL strings and not directly specifying the Query-AST? Admins, sure (a fancy UI could help there as well) but why in our code?

I’ve been trying to do exactly this. It must be possible.

Re: SQLite: Past, Present, and Future

#95

Earlier quoted context omitted.

Can you give an example of what you mean, and what we'd gain from it?

When you're accessing a SQLite database in code you have to generate a query string. Parameters ameliorate that somewhat, but in many cases you still have to regenerate a new string for each new query. It's inefficient to translate your query into a string only to have it parsed back into something structured by SQLite.

Is that a fact or an intuition?

Re: SQLite: Past, Present, and Future

#96

Earlier quoted context omitted.

Can you give an example of what you mean, and what we'd gain from it?

When you're accessing a SQLite database in code you have to generate a query string. Parameters ameliorate that somewhat, but in many cases you still have to regenerate a new string for each new query. It's inefficient to translate your query into a string only to have it parsed back into something structured by SQLite.

Are you suggesting an alternate syntax for SQL-like queries, which is more compact?

Or a specific one for SQLite?

I'd be very surprised if generating the SQL query string and parsing it again was more than a trivial percentage of the query execution time, but happy to be proven wrong.

Re: SQLite: Past, Present, and Future

#97
post #92
post #90

After seeing one diagram: Why the hack are we still talking to databases with SQL strings and not directly specifying the Query-AST? Admins, sure (a fancy UI could help there as well) but why in our code?

Why not?

Same reason you don't read files by concating string commands into another different language and then posting them to the OS.

Re: SQLite: Past, Present, and Future

#98
post #90

After seeing one diagram: Why the hack are we still talking to databases with SQL strings and not directly specifying the Query-AST? Admins, sure (a fancy UI could help there as well) but why in our code?

> Why the hack are we still talking to databases with SQL strings and not directly specifying the Query-AST?

The same reason language servers took off. Instead of one to one mapping, SQL enables one to many mapping with minor tweaks, allowing everyone to do whatever they want over a well known, well defined, mature abstraction.

In the same spirit, I may ask why we're not writing assembly or even machine code, and we have programming languages? Testers, sure, abstraction means clarity up to an extent, but why the developers themselves still use programming languages?

Re: SQLite: Past, Present, and Future

#99
post #90

After seeing one diagram: Why the hack are we still talking to databases with SQL strings and not directly specifying the Query-AST? Admins, sure (a fancy UI could help there as well) but why in our code?

Because query parsing time is totally insignificant compared to query IO?

I mean, I get it but the chances that it makes a noticeable difference are zero in almost every case. Also you'd have to change a lot of the existing tooling, at which point you might as well send a compiled agent or use stored procs?

Re: SQLite: Past, Present, and Future

#100
post #90

After seeing one diagram: Why the hack are we still talking to databases with SQL strings and not directly specifying the Query-AST? Admins, sure (a fancy UI could help there as well) but why in our code?

I believe most sql engines cache the query plans for parameterized queries, which would cover the majority of requests.

Caching the query plan is also going to go further in performance optimisations than just “precompiling” the SQL to a AST.

Post reply on HN