I want a branch-able schema. Migrations aren't a great for that. If you switch branches on your codebase, you'd need to revert the migrations back to the common ancestor, then apply the migrations in the branch. I'd like schema branching that is as easy as git branching.
Ideas to improve the user and developer experiences of databases
31–40 of 56 posts
Re: Ideas to improve the user and developer experiences of databases
#32I'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 exist 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 -for some-, 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 fact, 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.
And is done to JS with wasm. If is possible to do it for JS, sql is piece of cake.
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?
Re: Ideas to improve the user and developer experiences of databases
#33RethinkDB hit many of those spots. Schemaless, built-in management interface, metrics, sharding, streaming...
The closest thing right now is ArangoDB but it seems to swing too hard in the other direction (a boatload of features including a built-in web server).
Re: Ideas to improve the user and developer experiences of databases
#34This author is spot on. Raise your hand if you've committed the PostgreSQL to memory for looking at the DDL for a table, or identifying slow queries. Too many database management operations require highly specialized knowledge about a given database's internals. Folks are far too willing to spend huge money on expensive licenses for db analytics tools to tell them when queries are slow or suboptimal. Love the idea of…
Why would I want to have the examine DDL or slow query query committed to memory? I need to know that the concept exists and I can google the syntax in 90 seconds. I’m never within 90 seconds of disaster avertable with this knowledge.
You dont, you just have so many times that it happens (me.)
Re: Ideas to improve the user and developer experiences of databases
#35The main thrust seems to be tooling in the db to give developers some idea of the performance impact of the code they write. But most programmers are using frameworks and ORMs and things that hide away what is actually happening with the database. A normal developer can look at a chunk of code on their side and have no real idea of what is happening on the database behind them. What webdevelopers need is backend prof…
You could easily instruct the orm to add a comment in front of the sql query so the database can profiling of a complete http request and show you all the bad things your orm is doing. Something like: /* dbxperience:request=9a7cd2a6 */ SELECT .... I have not tested it, but this is something google cloud sql recently promoted: https://cloud.google.com/blog/products/databases/get-ahead-o...
You don’t need to go this path; modern(-ish) APM systems like Datadog will let you trace SQL commands in the context of the request being made. You can group by endpoint, or group by sql (merging IDs that differ), or chop and filter the data however you need. The DB is not in a position to give you all the stats you need; instead the DB should support e.g. exporting plan info to further enrich the whole-request metrics that are already being collected.
I use this in prod; it’s great. Expensive though.
https://www.datadoghq.com/blog/mysql-monitoring-with-datadog...
Re: Ideas to improve the user and developer experiences of databases
#36The main thrust seems to be tooling in the db to give developers some idea of the performance impact of the code they write. But most programmers are using frameworks and ORMs and things that hide away what is actually happening with the database. A normal developer can look at a chunk of code on their side and have no real idea of what is happening on the database behind them. What webdevelopers need is backend prof…
Apollo's GraphQL server has a VSCode plugin that shows you the average response time of a query. This type of tooling is difficult to implement but I think can be super useful.
https://marketplace.visualstudio.com/items?itemName=apollogr...
Re: Ideas to improve the user and developer experiences of databases
#37RethinkDB hit many of those spots. Schemaless, built-in management interface, metrics, sharding, streaming... The closest thing right now is ArangoDB but it seems to swing too hard in the other direction (a boatload of features including a built-in web server).
Schema less causes more problems that it solves. You still have an implicit schema, it's just now scattered all over your app.
Re: Ideas to improve the user and developer experiences of databases
#38I opened this article, ctrl+f'd for "branches" and was disappointed.
My #1 feature request from PostgreSQL would be a way to branch the database easily with my git feature branches that is smarter than keeping N copies of everything and syncing them as needed.
Re: Ideas to improve the user and developer experiences of databases
#39I want a branch-able schema. Migrations aren't a great for that. If you switch branches on your codebase, you'd need to revert the migrations back to the common ancestor, then apply the migrations in the branch. I'd like schema branching that is as easy as git branching.
Interesting, that would imply merge-able schema (and the ability to resolve merge conflicts in data too).
Re: Ideas to improve the user and developer experiences of databases
#40I think TerminusDB is interesting in this space. https://terminusdb.com/