From: John Cowan <xxxxxx@ccil.org>
Date: Friday, September 13, 2019 12:16 PM
1) Nicer syntax for SQL than strings - I count SSQL in that camp and use
it as such myself! The transformation here is purely syntactic, but even
then it's complicated, as Peter's blog post illustrates.
Too complicated for me, that's for sure. I'm not a big believer in porting applications across databases anyway: it hardly ever happens.
It happens in extremis. For example, my DB2 experience came about because the Minimum Viable Product level infrastructure for a startup providing services that I joined was built on the Microsoft Jet Database Engine, what Access uses. Wonderful and very solid engine as of then, but obviously didn't scale as the company gained more customers, so I did a painful port of code and data to DB2, chosen because it cost half as much as Oracle.
On I assume a longer time scale, from everything I hear a lot of shops are moving post-haste from Oracle to PostgreSQL because Oracle has turned their extortionist ways up to 11 to force people to move to their cloud. As mentioned before, it's not uncommon for shops with substantial MySQL investments to move to PostgreSQL.
There's another angle to this. What if you want to write an application that'll run on the customer's choice of database, within reason? Per Wikipedia SAP gave up for R/3's successor and moved to their own in-memory, column-oriented database. There's quite a few other boutique RDBMSs out there, I gather it's a lot easier to write them now that hardware has evolved so much.
*Why* would someone want to change databases? I'd guess either performance, or integrity, of the database or the data inside it.
What sort of examples can we think of where that might be desired by a Scheme user? Exactly the same as the example I mention above, if your use of an application outgrows the inherent limits of SQLite which occupies the same ecological niche as Jet. Perhaps PostgreSQL as it is today to SQL Server or something also heavy duty and commercial?
Making higher-level libraries work on any database is a more plausible goal, but extremely hard.
[...]
That does seem to be the trick. Especially since with one of the reasons is performance, and that encourages you to take advantage of a particular database's special features, especially before you go through the pain of moving to another database.
- Harold