Hacker News Reader

Comment by tabtab | Hacker News Reader

Why isn't there an HTTP protocol like "Query:" or "SQL:" such that drivers and ODBC/JDBC are not required to talk to a typical database? In other words, a database web service standard. Here's a sample of what the XML could look like:

https://www.reddit.com/r/Database/comments/p21u5d/standard_q...

View on HN

For completeness, FlightSQL[1] (as mentioned elsewhere in this thread) aims to provide such an HTTP based protocol

https://arrow.apache.org/blog/2019/10/13/introducing-arrow-f...

HTTP is stateless, whereas most database connection protocols are stateful.

So if you use HTTP, you need a lot of boilerplate on the client side to manage that state (eg. prepared queries, transactions, session parameters).

Probably because a bunch of these databases, and odbc, predate http and "web services" by many years.

It generally takes roughly 5 years for such standards to trickle into common systems. But separate software could make a server gateway/portal to those database products without it. In other words, a server-based adaptor. Database-vendor-specific services could be fairly easily built in say PHP or Python. They'd still conform to the standard (using XML and/or JSON), but only implement a gateway for specific database brands. It's a start...

Sure, that could be done... but it would be dramatically slower that any of the existing drivers. As much as the vendor drivers / odbc / jdbc have their annoying quirks, the wire protocols are pretty efficient.

It could have a binary format option (in addition to those formats listed). But also many kinds of apps don't need heavily compressed/compact data transfers. The "old" way won't go away, just have an alternative.

Ok, but they already have a binary format...

What is the advantage of your hypothetical binary format (which doesn't exist), (in addition to those formats listed), over the binary formats which have existed for decades?

Adding a layer slows things down and uses more memory, even if just a tiny bit, but for large result sets, I fear it will be a lot.

In addition it likely initially a) will be buggy and b) won’t support every feature of every vendor.

I think that’s a hard to win battle.

Reply on news.ycombinator.com