One of the first things I got told about databases is that you may build the most beautiful database schema for the domain, but it will never be able to be complete.
For the applications that I designed so far, that meant that I always made room for intentional loopholes like free-form comments or ways to override hardcoded processes. It is not 100% perfect and foolproof, but it made using these applications a lot less painful in practice.
A wholesale return to paper is like trying to put the genie back into the bottle. It is really about how rigid a process can become without becoming a barrier or burden.
I really like the idea of intentional loopholes. It is a great way ton conceptualize what I have been doing for a long time.
In my opinion there is a certain feeling of satisfcation when feeling like the domain is modeled completely. Uncertainty or loopholes leave an itch to scratch. That's why people insist on modelling addresses.
Adresses which are a fundamentally easy thing, should be easy to model.
Like what, a house is on a street, has a number a city a state and a postcode. All of them are obviously required. And then you get into actual addresses. People who live in a village without a street. Some countries have no states. Some names can be extremely long. For example my condo adresss is 62 characters alone.
I think the only thing you can rely on for addresses is postcode, city and the rest is free form. But that feels so unsatisfactory.
Addresses are hard. Off the top of my head: I live in Germany. Germany has states, but they are not part of postal addresses. A lot of US sites keep insisting on entering a state wven though that is wrong. There are tiny villages without street names. The name of the village substitutes for the street name. Maybe there are single house settlements with house numbers - I am not sure.
And then there is Mannheim, a city with no street names. This was originally a planned city where the city center has rectangular blocks numbered in a letter-number scheme. So there is e.g. a block L5. This refers to one side of the 4 adjacent streets. The other side of these streets is addreseed with L3, L5, etc... what his means is that you have addresss like O7 6 - a single letter and two numbers in a row. I bet that a lot if input validators for addresses trip over something like that.
Superior strategies like this are like hidden lore. Why is that? I'm certain there are dozens or hundreds of these hard won lessons.
I had to rediscover the "INSERT only, no UPDATEs" trick on my own. Changed from separate truth and historical tables to a single table which is groomed over time. Major simplification. A few extra benefits: like scaling, testing and auditing.
And my peers absolutely lost their minds. A senior VP rolled back my architecture the moment he could. (We were acquihired, so this meant major upheaval of systems which had be in use for over 3 years.) My solution was just too weird looking, too unorthodox.
So while there's lots of things we can do to mitigate databasization and buy ourselves some head room, we don't.
Square peg, round hole?
My radical (unoriginal) thought is the problem is the people, not the tools.
Sorry, this is example of my muddled thinking. Here's another shot:
Real world is messy, evolving. Schemas and programming languages encourage rigidity, but can be more flexible. So while we can design and use adaptable systems, we don't.
An additional theory I have is that the people drawn to our type of work have rigid views and strive to make the world more ordered, through their systems, rather than accommodate the chaos. Aspirationally. Not in truth. Because I regard most of our efforts to be rather chaotic.
For the applications that I designed so far, that meant that I always made room for intentional loopholes like free-form comments or ways to override hardcoded processes. It is not 100% perfect and foolproof, but it made using these applications a lot less painful in practice.
A wholesale return to paper is like trying to put the genie back into the bottle. It is really about how rigid a process can become without becoming a barrier or burden.