Some technical design elements can enable this style of non-programmer usage that most databases engines do not currently support.
First, treat each column separately in the physical engine (column store). Users ought to never need to worry about column count limits, row byte limits, or sparsity. Similarly, schema operators such as adding, removing, or reordering columns ought to always be instant atomic changes.
Imagine how much faster it would be possible to explore the schema design space if changes were instant and didn’t require “migration scripts” or data copies from an old table to a new one. It would make the database feel more like a spreadsheet!
Next, there ought to be Git-style forking and merging so that creating a test environment should also be a lightweight operation just like creating a local branch in a Git repo. Merging changes can be either schema only or schema+data -- the latter to support slowly-changing “master data” editing workflows. Currently, few if any database support the equivalent of a pull request with reviews to merge data. Hence the excessively complex access controls that could all be replaced with a single "peer review" operation.
I’ve seen a fancy category-theoretic approach where forks of the database can receive live data updates from production. This would allow UAT and similar environments to be evergreen with zero infrastructure code such as nightly ETL sync jobs.
Many operational tasks can be eliminated by tying live environments of both the code and data to Git branches of a single (mono) repo. Now the code and data schema can’t go out of sync! Literally impossible. No need for scaffolding, or ORMs, or any of those layers of overcomplicted abstractions! The schema is just “there”, in the repo, always representing reality.
Sprinkle on a Microsoft Access style form designer but with HTML5 and guest user support and you have a billion dollar product.
First, treat each column separately in the physical engine (column store). Users ought to never need to worry about column count limits, row byte limits, or sparsity. Similarly, schema operators such as adding, removing, or reordering columns ought to always be instant atomic changes.
Imagine how much faster it would be possible to explore the schema design space if changes were instant and didn’t require “migration scripts” or data copies from an old table to a new one. It would make the database feel more like a spreadsheet!
Next, there ought to be Git-style forking and merging so that creating a test environment should also be a lightweight operation just like creating a local branch in a Git repo. Merging changes can be either schema only or schema+data -- the latter to support slowly-changing “master data” editing workflows. Currently, few if any database support the equivalent of a pull request with reviews to merge data. Hence the excessively complex access controls that could all be replaced with a single "peer review" operation.
I’ve seen a fancy category-theoretic approach where forks of the database can receive live data updates from production. This would allow UAT and similar environments to be evergreen with zero infrastructure code such as nightly ETL sync jobs.
Many operational tasks can be eliminated by tying live environments of both the code and data to Git branches of a single (mono) repo. Now the code and data schema can’t go out of sync! Literally impossible. No need for scaffolding, or ORMs, or any of those layers of overcomplicted abstractions! The schema is just “there”, in the repo, always representing reality.
Sprinkle on a Microsoft Access style form designer but with HTML5 and guest user support and you have a billion dollar product.