Quite a few of the multitude of tiny problems one faces creating a CRUD come from the fact that the software is divided in layers. The modern implementations are universally composed of 3 layers, all run by different software, usually on different computers.
Let's call those that "data" layer, that runs in a RDBMS, "transformation" layer that runs in a web server, and "presentation" layer that runs in a web browser.
The separation of those 3 layers creates all sorts of integration problems, that forces people into writing the same code for each one of them. Worse yet, while the data layer affords a lot of requirement analysis (done before the fact), and the transformation layer affords a lot of code analysis (done after the fact), no software quality methodology is equally afforded by all 3, and most of that analysis is not extended to any other layer.
So, not only people have to write their code multiple times, there are very little know-how on ensuring that those copies are correct or even coherent with each other.
People also really like to create multiple layers inside the transformation layer itself. Usually trying to follow a model-view-controller architecture. (Ha! Nobody even agrees on what MVC is, so good luck on following it.)
That, of course, fixes nothing of the problem of excess of incompatible layers, but instead just adds a bit more of it.
Anyway this is a self-imposed problem, so just don't. There isn't much more to say.
That kind of problem is usually solved in two variations of the same way.
There is the insane way, where one creates a very complete and detailed specification of what parts of the program must be created on each layer. And optimally some automatic verification that any layer is doing exactly its job. Any part of the program that must run in one layer, but belongs in another one must be derived from the other layer.
Currently, when people try to solve this problem, this is the most popular approach.
The other way is the sane way, where one creates every single thing on the same place. The code is then split into layers completely derived from it and that must not be changed directly in any way.
And how does one synchronize the behavior of all layers so they are coherent? Well, you can generate lots of code... or you can make them polymorphic. Any complete solution will probably do a bit of both.
But if you want to generate code or resolve polymorphism, you need some metadata to guide you. On programs, that metadata comes from the type system.
(But does all of the relevant metadata really has the form of types? I guess I should think more about this later.)
Inter-program data sharing
A similar problem appears on the interface between different programs. Either them being services where one program explicitly calls the other, or just different workflow steps that have to guide their users into a next one.
Again, ideally one should define their data and behavior only once, and both programs should be able to use it. But this is harder to do here.
On a less ideal scenario, one can reuse the same analysis and verification in both programs.
But well, this is a widely studied problem, with very mature solutions. You do that by sharing a schema. There isn't much to add specifically to this...
Except on the subject of access control.
You see, access control is usually done with very little theoretical underpinning. And incredibly scarce tooling. And yet, something that every CRUD must solve perfectly.
Databases have an entire subsystem for it. But because of the solve-everything-3-times philosophy, it's not normally used to control the accesses of people.
It's also hard to share its rules between different systems.
Any data definition aimed at CRUD should give access control a similar amount of focus it gives to data correctness.
And export its rules in schemes.
And distribute the same rules between all layers.
And allow for rules verification (it should allow for correctness rules verification too).
And allow for rules documentation.
And none of this exists for any widely used language or environment nowadays.