3 ms·

> the startup overhead of an SQL system is a myth. It's also a myth that devs choose NoSQL over SQL because "SQL is too hard."

tracker1 9y ago
Can't speak for anyone else... for me, it was the shape of the data I was interacting with was best represented as nested objects... think a classifieds site... primary record is the ad/entry, but different types of products will have differing ancillary data. That was my use case in first using MongoDB. Why, because otherwise there were up to 30+ joins in order to bring up all the data around any given classified entry. Reshaping the data into a document store, with a handful of indexes made a lot of sense. Nearly effortless replication was also a nice feature, and needed for some extra endurance and scale. I'm pretty sad that RethinkDB didn't get farther, as their management interface and approach was a lot better than MongoDB. To me it's about what does the data look like, what are the performance needs, and how much do you want to spend, cross-train or hire out expertise. Not to mention the lock-in options. There are lots of options, and it depends on the project and use. I've worked in enough applications where at least parts of the application needed to be moved off of SQL short of spending FAR more on licensing and/or servers that were insanely expensive for the need the value wasn't good.
kafkaesq 9y ago
It's also a myth that devs choose NoSQL over SQL because "SQL is too hard." What I see more of is situations where the developers "know" SQL but still just don't want to sit down and figure out their data models. It's like, the temptation to reach for the nearest short-cut -- whether that means over-reliance on ORMs (or hodgepodge 'data access layers'); or continually munging stuff at the application layer for nearly every operation; or... Mongo -- is always just too great.
- bryanrasmussen 9y ago
  figuring out the data model as you build can be beneficial, you realize what you need as you work with the thing and can add it on the fly, at a certain point of course you need to do a cleanup. Getting people to accept the cleanup requirement is the difficult part.
thehardsphere 9y ago
Unfortunately, it's one of those myths that is prevalent enough because there are enough proponents of NoSQL who give it as their reason for doing it. Kind of like how people also say they choose Node.js so they only have to use one language on the server and the client.

tracker1 9y ago

Can't speak for anyone else... for me, it was the shape of the data I was interacting with was best represented as nested objects... think a classifieds site... primary record is the ad/entry, but different types of products will have differing ancillary data. That was my use case in first using MongoDB. Why, because otherwise there were up to 30+ joins in order to bring up all the data around any given classified entry. Reshaping the data into a document store, with a handful of indexes made a lot of sense. Nearly effortless replication was also a nice feature, and needed for some extra endurance and scale. I'm pretty sad that RethinkDB didn't get farther, as their management interface and approach was a lot better than MongoDB. To me it's about what does the data look like, what are the performance needs, and how much do you want to spend, cross-train or hire out expertise. Not to mention the lock-in options. There are lots of options, and it depends on the project and use. I've worked in enough applications where at least parts of the application needed to be moved off of SQL short of spending FAR more on licensing and/or servers that were insanely expensive for the need the value wasn't good.

kafkaesq 9y ago

It's also a myth that devs choose NoSQL over SQL because "SQL is too hard." What I see more of is situations where the developers "know" SQL but still just don't want to sit down and figure out their data models. It's like, the temptation to reach for the nearest short-cut -- whether that means over-reliance on ORMs (or hodgepodge 'data access layers'); or continually munging stuff at the application layer for nearly every operation; or... Mongo -- is always just too great.

bryanrasmussen 9y ago
figuring out the data model as you build can be beneficial, you realize what you need as you work with the thing and can add it on the fly, at a certain point of course you need to do a cleanup. Getting people to accept the cleanup requirement is the difficult part.

thehardsphere 9y ago

Unfortunately, it's one of those myths that is prevalent enough because there are enough proponents of NoSQL who give it as their reason for doing it. Kind of like how people also say they choose Node.js so they only have to use one language on the server and the client.