> Formalising 3rd normal form and giving it a rigorous definition so that we can test if data is properly normalised is a big deal.
It isn't. Half the world already relies on ORM frameworks that barely require any input from the developer to setup relational databases, let alone knowledge on how to normalize them.
On the rare occurrences a project feels that specialization on relational database design is relevant, more often than not it's far more useful to require expertise on specific RDBMS than trivia tricks.
> If those things aren't math to you (...)
You're missing the whole point. No one is arguing that you have math formalisms. The whole point is that those formalisms do not add any value at all. Don't you understand that?
I mean, I can whip out a web app with multiple services running in the backend and with datastore using both DynamoDB and S3, and build a business around it. We can do this without ever knowing who Jack or Joe or Jim or Jose Cobb was, let alone what he wrote. What does it tell you?
> The whole point is that those formalisms do not add any value at all. Don't you understand that?
I'm going to go a bit further than just not understanding, I'm actively disagreeing with you. Based on your arguments here, in a workplace I would advocate not letting you make any decisions about database schema.
Sounds like the feeling might be mutual there though. Not saying you're bad at whatever it is you do; just I want to have to have schema designed by someone who has thought deeply about schema design. Databases usually outlive all the employees assembling it, can outlive an entire organisation and getting the design right can save days to months of work.
The academics have got entire classes of bugs that they can demonstrate don't exist in normalised data, there are benefits to everyone coordinating around a standard shared view on how to lay out data and usually drifting away from the standard it turns out not to lead to real benefits long term. You can believe that is valueless or isn't math or whatever, but there is no point aggressively introducing opportunities for bugs when there is no reason for it. And to avoid doing that, the person making the decisions needs to understand the theory.
"Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won't usually need your flowchart; it'll be obvious." -- Fred Brooks, The Mythical Man Month (1975)
It's unfortunate that most people these days prefer unstructured blobs of json to formal relational databases. It's impossible to get up to speed in these types of environments because every time you think you "understand" the data, you find out about a random property that gets set in rare occurrences that throws off the whole relational model you intuitively built in your mind.
People who excel at theory usually don't do well in most programming positions. Perfectly normalized schemas do not hold up well in an operations heavy environment.
I'm not advocating for perfectly normalized schemas. There's a large gap from: perfectly normalized schema -> unstructured blob of json. I'm saying that most people nowadays prefer to not think at all about how their data looks and they'll add properties ad-hoc.
This also does not hold up well in an operations heavy environment. Like all things in programming, a well balanced approach is necessary. Some combination of formally structured data with some flexibility for future requirements is probably the best course of action here, but that's too much work for programmers these days.
If you think an ORM somehow saves you from having to know how to make a normalized DB schema (even by intuitive means instead of formal ones), you've lost your mind. For most 9-5 developers just earning their paycheck, this train of thought can lead to absolutely fucking insane DB thrashing and data consistency problems. You might be getting away with it intuitively, but a lot of people won't, so keep it to yourself for your own sake.
It isn't. Half the world already relies on ORM frameworks that barely require any input from the developer to setup relational databases, let alone knowledge on how to normalize them.
On the rare occurrences a project feels that specialization on relational database design is relevant, more often than not it's far more useful to require expertise on specific RDBMS than trivia tricks.
> If those things aren't math to you (...)
You're missing the whole point. No one is arguing that you have math formalisms. The whole point is that those formalisms do not add any value at all. Don't you understand that?
I mean, I can whip out a web app with multiple services running in the backend and with datastore using both DynamoDB and S3, and build a business around it. We can do this without ever knowing who Jack or Joe or Jim or Jose Cobb was, let alone what he wrote. What does it tell you?