Our great sponsors
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
Re: Stackoverflow and showing profiling information on the front end, you are likely talking about Miniprofiler.
I'm worked on the side in a relational language (https://tablam.org) and have used FoxPro, that in a lot of ways is superior to any RDBMS of today.
The ideas here are very good! But excise many other things that could have a greater impact:
1. We need an "wasm" for sql.
SQL is not a good language to transpile to.
ALL ORM ARE TRANSPILERS!
The relational model allow to do so much with so little (you don't even need to create a foreign procedural language if you add basic programming constructs). In FoxPro, you DB lang, your query lang and your programming lang was one and the same.
Much better.
Now today this could not fly, but a "wasm/llvm little" tailored to rdbms could be a very good idea.
Is exactly what things like GraphQL are, sadly, GraphQL is not made for DBs and is a hostile target for them.
1a: "But who will replace SQL, that is nuts!"
This is the major excuse. But things like graphql show is possible.
The "trick" is that this new query lang is SERVER SIDE. Developers will use it if is nice, and the major work is on libraries.
Solve this is not as hard as people think. In fan, is done MANY TIMES BEFORE!. But most not see it because not understand that what we are doing with SQL is making ad-hoc compilers.
2- We need Algebraic types: eliminate NULLS from their last bastion
Have algebraic types as first class will be a very good improvement here. No more null shenanigans, and will match what we know as today as best practiques.
Plus, will allow to fulfill better the ideal of a DB of "data modeling" of business requirements.
3- The auth support of RDBMS is for a bygone era.
The article show it, but the truth is that "nobody" use the auth support of rdbms outside some niches. A modern rdbms only need the equivalent of JWT and the ability to do custom auth checks. This will allow to actually plug the auth that is tailored to the app via:
4- We need "sql install simple-auth" aka: Package manager
As I said, I use fox pro. it was a full feature programming environment. This mean I have frameworks/libraries that I could distribute or integrate. A DB can benefit to install packages and declare its dependencies like with rust.
This could be great for example, to install a well vetted auth support for the db, or logging, or tracing, or extra functionality like fts.
And how about use wasm as the binary interface?
Regarding the thoughts on migrations, which I 100% agree with, one strategy for cutting down the steps in a migration is to make the application compatible with the schema both before and after the migration. This can either be done by checking the migration sequence number, or by detecting the actual schema change. Using the author's example, where the migration involves a transition from an old table to a new table, you would make the application able to read/write using any combination of the tables. Then you can run your migration and/or move data. Later on, clean up the conditionals in the application code.
---
And on a different topic:
The Java SQL/database library, jOOQ [1] comes with a code generator that allows you to generate Java classes corresponding to your schema. This is pretty cool because it enables type-safe query building. It's a bit like connecting Java's type system to the database's type system. I find this to be really useful for ensuring correctness.
And if you're taking the approach from the first half of my comment, you can generate code any versions of the schema you need in the application.
[1] https://www.jooq.org/ jOOQ is really cool for a lot of reasons. The code generator is just one piece of it. For example, it can be used to translate between different vendors' dialects.
If you're using Postgres, check out dexter[0].