3 ms·

> By what metrics can we say the product is one worthy of passing a HN smell test? Common sense and formal education? I'm sorry, I'm aware of how incredibly sn

by anyfoo 8y ago

> By what metrics can we say the product is one worthy of passing a HN smell test? Common sense and formal education? I'm sorry, I'm aware of how incredibly snarky and arrogant that sounds, but in this case I always struggled to comprehend how MongoDB, or most of "NoSQL" in general, was considered viable to begin with. "Schemaless" just immediately means that instead of the database keeping consistency, you now essentially have to do all your type and constraint checking in the application; I never understood how that's favorable, and how that remains maintainable in any way. On top of that, NoSQL (and maybe Mongo in particular?) also decided to throw away all guarantees that classical SQL databases have been offering for multiple decades for very good reason. I think everyone who's had a somewhat theoretical class on databases and learned about, for example, what ACID really means, will have smelled that something doesn't quite add up here.

mooreds 8y ago
> "Schemaless" just immediately means that instead of the database keeping consistency, you now essentially have to do all your type and constraint checking in the application... This is so true. Some component has to maintain integrity of the data. Should it be the application developer? Or the database software team? I know which one I'd choose, and which one is focused on data integrity and not business logic.
- anyfoo 8y ago
  And it’s not just who you trust, it’s also at what layer you want to enforce your integrity and consistency. Not letting the db do that means that every part of the application that touches the database needs to do that enforcement. Even if you abstract that away into a strict layer directly above the database—which essentially means you’ve just implemented parts of a database on top of a database—you have to essentially invent and implement the methods and languages to do so yourself. At which point you’re pretty much guaranteed to be much worse of then if you had just let the DB do it. This might mean handling unexpected errors if you have a bug in your application logic, but that’s usually orders of magnitude better than introducing hard to fight inconsistencies.
- jerrysievert 8y ago
  > This is so true. Some component has to maintain integrity of the data. Should it be the application developer? Or the database software team? if you're using partitioned (inherited) tables in Postgres, then it's the application developer, as foreign keys on inherited tables don't really work. the workaround is triggers.
quickthrower2 8y ago
I also don’t see the benefit of schemaless. Schemes have been way too useful in my programming career. But eventual consistency may be a viable trade off to help you scale, but the thing is you probably need to be at a massive scale before it is worth moving away from traditional SQL, which can have read replication and the app can have caching too. But there is probably some point at which eventually consistent nodes make sense. In a sense that is what a CDN is, and we like to use those.

by anyfoo 8y ago

mooreds 8y ago

> "Schemaless" just immediately means that instead of the database keeping consistency, you now essentially have to do all your type and constraint checking in the application... This is so true. Some component has to maintain integrity of the data. Should it be the application developer? Or the database software team? I know which one I'd choose, and which one is focused on data integrity and not business logic.

anyfoo 8y ago
And it’s not just who you trust, it’s also at what layer you want to enforce your integrity and consistency. Not letting the db do that means that every part of the application that touches the database needs to do that enforcement. Even if you abstract that away into a strict layer directly above the database—which essentially means you’ve just implemented parts of a database on top of a database—you have to essentially invent and implement the methods and languages to do so yourself. At which point you’re pretty much guaranteed to be much worse of then if you had just let the DB do it. This might mean handling unexpected errors if you have a bug in your application logic, but that’s usually orders of magnitude better than introducing hard to fight inconsistencies.
jerrysievert 8y ago
> This is so true. Some component has to maintain integrity of the data. Should it be the application developer? Or the database software team? if you're using partitioned (inherited) tables in Postgres, then it's the application developer, as foreign keys on inherited tables don't really work. the workaround is triggers.

quickthrower2 8y ago

I also don’t see the benefit of schemaless. Schemes have been way too useful in my programming career. But eventual consistency may be a viable trade off to help you scale, but the thing is you probably need to be at a massive scale before it is worth moving away from traditional SQL, which can have read replication and the app can have caching too. But there is probably some point at which eventually consistent nodes make sense. In a sense that is what a CDN is, and we like to use those.