Playing the devil's advocate: Why write SQL at all? Lassi Kortela (12 Sep 2019 10:02 UTC)

Playing the devil's advocate: Why write SQL at all? Lassi Kortela 12 Sep 2019 10:01 UTC

Been wondering about this for a few years.

1. Programmer writes queries in SQL. SQL has few reflection or
metaprogramming capabilities. A SQL query is a string embedded in a
foreign programming language. Quoting is difficult to get right.
Prepared statements do not read naturally (variable references are just
question marks or other placeholders) and do not generally support
reflection (e.g. a query variable cannot specify a table name).

2. DB library wastes time parsing the programmer's SQL into a binary
format that is easy for the DB engine to optimize and execute.

Given that billions of queries are done around the world every second,
why isn't there a standard binary format for this stuff? That format
could be generated directly from e.g. a S-expression based Lisp DSL,
would support easy metaprogramming, and would instantly avoid all the
quoting gotchas and all the unnecessary parsing.

There are many DSLs (even many without object-relational mapping, such
as Roda for Ruby or Korma for Clojure) but they all convert to SQL under
the hood for no particular reason.

Some DBs (Oracle, Postgres) have custom drivers or protocols that
presumably use a binary format. Could something be generalized from these?

I'd love to have a clean generic socket/pipe DB protocol, and then we
could just simple write driver programs in C to plug in different
databases using their native C libraries. Even SQLite could be plugged
in as a subprocess. Database operations tend to be slow enough that
using an external process probably doesn't hurt for any normal usage. As
for bleeding-edge things like high-frequency trading, they probably have
their own database engines anyway.