[sgarland]

I am personally offended by [0]. Maybe you should spend some time doing proper data modeling when you design your app, and maybe adding a new column should be a painful exercise.

Haphazard schema is the quickest way to develop terrible performance, loss of referential integrity, and insane queries. Well, outside of sticking everything into a JSON column.

0: https://worstofbreed.net/patterns/schema-bureaucracy/

[esseph]

stands up I'll admit one of my sins

I have occasionally stuffed json into proprietary software data fields to get that data accessible/usable by another system.

(High performance not required)

[netbioserror]

I've used JSON as an additional options input to a native-compiled CLI program's various commands because 1) the schema of each option is radically different, 2) they need to be passed most of the way down the call stack easily for each stage of our calculation and report generation.

It works fantastically well, and don't let anyone tell you that you MUST bloat the CLI interface of your program with every possible dial or lever it contains. We should all be cogent of the fact that, in this very young and rapidly evolving profession, textbook and real-world best practice often do not overlap, and are converging and diverging all the time.

[neilv]

That could be a virtue.

And some closed proprietary software does things like adds a few additional fields for pragmatic end user extensibility like this.

The practice predates JSON, but sometimes your bespoke string or ID or whatever in field "Custom 1" is all compromise you need to make things work well.

[sgarland]

OK… there are some exceptions where it makes sense. In the web dev world, though, the overwhelming majority of cases I’ve seen it used are along the lines of “we don’t know what we might need later,” AKA “either product didn’t adequately specify the requirements, or we didn’t do proper data modeling.”