Hacker News Reader

Comment by tscs37 | Hacker News Reader

Totally agree. I've wet my toes with NoSQL systems but things like MongoDB just look like trouble waiting to happen.

On the other hand, SQL makes it hard to maintain the state definition, I had to develop a mechanism to upgrade the DB from any possible state to the latest state.

Still, this allows me to define very accurately what is a valid row or entry in the database, which means my Applications need to make far fewer assumptions.

I can just take data from the DB and assume with certainty that this data has certain forms, formattings and values.

MongoDB makes none of these guarantees.

View on HN

It's absolutely true that migrations in SQL databases can be a pain. I don't actually think that's a bad thing - what's really going on there is that the DBMS is throwing data integrity issues into your face, and encouraging you to think about them.

A lot of developers don't want to do that, because they want to think of data integrity as this tangential concern that's largely a distraction from their real job. A lot of developers also have a habit of cursing their forebears on a project for creating all sorts of technical debt by cutting corners on data integrity issues, while at the same time habitually cutting corners themselves in the name of ticking items off their to-do list at an incrementally faster pace.

This isn't to say that NoSQL systems make your system inherently less maintainable. But I do think NoSQL projects gained a lot of their initial market traction by appealing to developers' worst instincts with sales pitches that said, "Hey, you don't even have to worry about this!" and deceptively branding schema-on-read as "schemaless". So a reputation for sloppiness might not be deserved (or at least, that's not an issue I want to take a position on), but, in any case, it was very much earned.

I am very fond of pushing as much validation into the database as I can, so I use `NOT NULL`, foreign keys, `CHECK` constraints, and whatever I can to let the database do the job of ensuring valid data. All of us make mistakes, and making sure there are no exceptions is just what computers are good at. I think you're right about "a lot of developers", but I find data modeling, including finding the invariants, pretty satisfying actually.

Reading your comment reminds me of ESR's point in The Art of Unix Programming that getting the data structures right is more important than getting the code right, and if you have good data structures, writing the code is a lot easier. The database is just a big data structure, the foundation everything else is built on, and the better-designed it is, the easier your code will be.

IMO validating in the DB also makes code faster.

When I get data from a well validated DB, I don't have to check that it is valid or has certain formats, that is ensured by the DB.

I can remove checks from the entire CRUD stack, if it's invalid data it does not get created or won't make it into the update.

The easiest way to check data is then to try the INSERT or UDPATE and if it works it's valid.

Otherwise I'd need to validate all fields, see if any contain errors, if any are missing, etc etc.

That's not ESR's point. It's shoplifted from Brooks.

>DBMS is throwing data integrity issues into your face, and encouraging you to think about them.

And I love it to death for it.

It also allows me to do some nifty little tricks.

I've developed my own Migration Tool that works by exploiting this data integrity, it actually aids me to identify and upgrade the database dynamically without worrying about which updates are applied and which not.

"MongoDB: Because /dev/null doesn't support sharding"

Minor point, but MongoDB added document validation in 3.2 so you can add guarantees about what documents are being stored.

https://docs.mongodb.com/manual/core/document-validation/

Reply on news.ycombinator.com