The single biggest source of grief in our production database has been the one JSON field we used once to avoid adding another table. That goddamn thing has crashed the server so many times with invalid data, that I'm never using anything schemaless again. We recently migrated to a proper table and I'm thanking my lucky stars I finally got rid of that devil.

JSON field? You are lucky. We have a Pickled python object stored in our database. Wonderful for debugging when its pretty much unreadable.

My condolences :(

> I'm thanking my lucky stars I finally got rid of that devil.

All that I can say is congrats, man!

Prototyping on Mongo is bad. MySQL takes 10 seconds to install. I'm imagining with the public Docker registry, so does Postgres.

How many times have you promised to fix something later and then later comes and...

Prototyping is not an excuse for laziness. It does feel like some programmers don't care.

You can insult the developers that use Mongo or you can look at how to get those users onto a better platform. With the modern expectations of full-stack development, is it any wonder that something promising simplicity and zero-configuration data storage does well?

> MySQL

Why not just prototype with Sqlite? You don't even need a server.

Well, I have used one and had that assertion. Ease of use means making something that works. It seems we're condoning lack of knowledge or experience with programming. If you've never used databases in your life, whether you're using SQL orNoSQL you'll likely end up with rubbish data. In the SQL world it could be that you're storing time in the wrong format, concatenating long fields, or not normalising when you should or the other way around.

In NoSQL you could be reinventing the wheel, or storing data that you can't query efficiently because you can't index it well etc.

All the excuses of not using some document stores beyond ACID really sound like people won't know what the heck they're doing.

> Well, I have used one and had that assertion. Ease of use means making something that works.

For me, it means, under no circumstance, no interleaving of transactions or scheduling of commands, nothing, nichts, nada, can the database be in a state where a business rule is violated. If I need to worry what silly intermediate transaction state can be observed from another transaction, or if I need to worry whether a master record can be deleted without cascade-deleting everything that references it, then the DBMS has failed me.

> not normalising when you should or the other way around.

I've never seen a situation where anything less than 3NF (actually, ideally, at least EKNF) is acceptable.