Comment by mattmanser

I've made automated form editors, companies I've worked for have done it. They had data nesting, with no custom functions for handling it. For example I've made a fully customisable menu editor where you could add sections, sub sections, prices to items, prices to sub items, prices for picking 2 out of X items in the menu. All sorts of crazy (optional) nesting. All saved in different tables. Took me like 2 weeks. I felt very clever at the time. Frontend was all in jQuery too!

They all saved to relational databases with multiple tables. One form editor (which wasn't mine), allowed you to add new columns (this was in the on-prem days and back then they avoided future collisions by prefixing the custom columns with ex_).

The problems you listed above are solveable. You don't need custom functions, you need clever property naming. Most ORMs have to solve them too.

So nested data is not actually a problem for lo-code solutions, it's a solvable/solved problem.

And I STILL regularly leave that sort of data denormalized. I write multiple date columns (e.g. created, lastUpdated, etc.). I still write mobile + work numbers as columns for plenty of apps.

Why? It's simple YAGNI. For many apps it's quicker and easier to denormalize the data and keeps the code much, much simpler.

Plenty of apps that I've seen that have been going 15+ years haven't normalized that data and it's fine.

The problem comes when no-one refactors and keeps adding them.

But it's extra work and it's "dangerous" work, potentially data destroying if you get it wrong.

You get no thanks, as other devs will moan it's more complicated to use, and if you slip up you might get fired.

So most devs take the easier and safer option and just add a new column.