3 ms·

> As I understand it you're saying that it's impossible or hard to have large parts of functionality in a standard compliant implementation. I think that you co

> As I understand it you're saying that it's impossible or hard to have large parts of functionality in a standard compliant implementation. I think that you could have extension features on top of standard, allowing users to use them when they choose to have extensions or not to use them when they need to have conformance to standards. I've had discussions regarding DB choice based on features which are in non-implemented standards enough to pay attention to the matter. No. I'm saying that the SQL Standard deals only with the querying language. It does not cover a million other aspects of database engines, that determine how well the databases are suited for different use cases (performance, tolerance to failures, single-node vs. distributed, OLTP vs. analytics). Those are the differences that make treating databases as drop-in replaceable naive - even if the databases were 100% compatible at the SQL level, you can't really replace them easily because the query language is just a tip of the iceberg.

avmich 9y ago
To me, drop-in replacement means the interface is the same, not implementation. You can have list operations on top of array, single or double linked lists etc., and you'll get different Big O numbers for different operations, different memory access patterns - but will still have the same append() and length() functions in the API. Drop-in doesn't mean "equivalent in all measurable aspects". I spend substantial time navigating and compensating for differences in DB interfaces - not characteristics of internal solutions. Standards aren't about that - they are, as I understand, to solve the problem which I have, because standards aren't followed. I want to be able to replace databases not because they are the same - what would be the purpose then - but because having the same interface (i.e., the ability to just replace the DBMS) they could provide me a choice of characteristics.

avmich 9y ago

To me, drop-in replacement means the interface is the same, not implementation. You can have list operations on top of array, single or double linked lists etc., and you'll get different Big O numbers for different operations, different memory access patterns - but will still have the same append() and length() functions in the API. Drop-in doesn't mean "equivalent in all measurable aspects". I spend substantial time navigating and compensating for differences in DB interfaces - not characteristics of internal solutions. Standards aren't about that - they are, as I understand, to solve the problem which I have, because standards aren't followed. I want to be able to replace databases not because they are the same - what would be the purpose then - but because having the same interface (i.e., the ability to just replace the DBMS) they could provide me a choice of characteristics.