5 ms·

I agree with this, but I'd add that we developers tend to make an RDBMS do everything because it's what they're familiar with. NoSQL is an alternative to solve

by bphogan 17y ago

I agree with this, but I'd add that we developers tend to make an RDBMS do everything because it's what they're familiar with. NoSQL is an alternative to solve a specific problem, but you can't see that problem if you're ignorant of it. It's like my experience with SVN vs Git. I didn't know how useful and more efficient my workflow would be if I used branches, so I never saw why Git was useful. Sure I could branch in SVN, but it was way more work. I got involved in a project where I had to use git, and I learned how branching works, and now I use it all the time because I understand where it's applicable. I don't think you have to choose MySQL over MongoDB. I think you could be very happy using both, each for its purpose. You don't always know why you need something until you need it. It's always good to keep an eye on what others are doing.

wvenable 17y ago
The same argument about branches in source control can made about SQL itself. In my opinion, a large number of developers don't know how to code SQL properly and a lot are afraid of it. They end up using an RDBMS as nothing more than a dumb bit bucket -- often hidden behind increasingly complex abstractions. The NoSQL movement, unintentionally, lets these programmers feel superior about their lack of knowledge. I don't want to argue against the legitimate use of NoSQL solutions. I just don't think there are enough use-cases to justify the hype. For example, an article was posted here last week about using NoSQL solution to store e-commerce orders.
- gte910h 17y ago
  I disagree. Lots of applications only require dumb bit buckets. There is no real sophistication or structure to the data. Anything more is over engineering for a large majority of products which data storage is not particularly useful or meaningful.
  - bphogan 17y ago
    I worked on a system a couple of years ago where we ran calculations nightly and then we write the results of this calculation to a row in a table for caching purposes. This row was then fetched by another job to generate a PDF. We used SQL for this because Reporting Services could build a pdf from a row in a table. It's not a good solution. This type of data doesn't need to be searchable. It's using a database server as a caching mechanism. That seems wrong. Seems like memcached, mongo, couch, or anything else would have been better. Heck, people have been using memcached for a long time, and yet all of a sudden people don't see a use for NoSQL setups? Are we sure we're not just doing the same old "Defend what you know" dance?
lucifer 17y ago
"SVN vs Git" An excellent comparative case in point that in my opinion actually undercuts what you are asserting. You do not lose features and functionality in that transition (where as noSQL is by design reductive), and further, Git is a replacement for SVN and not a complementary tool.
- bphogan 17y ago
  Actually you do lose functionality by going that way. SVN handles binaries better. I can also cherry-pick files from a directory structure, so if I need to fetch out a subfolder or an individual file, I can do so. With Git I must clone the repo or set up a web service so I can get access to the file system. But they're different tools for different audiences. In my environment, I do use both of these tools together. The lesson Git, Ruby, Subversion, Apache, and many other projects have taught me is that instead of saying "What I have is fine, I don't need what you have", I need to ask "Why do you use what you use, why does it help you, and how might it help me?

by bphogan 17y ago

wvenable 17y ago

The same argument about branches in source control can made about SQL itself. In my opinion, a large number of developers don't know how to code SQL properly and a lot are afraid of it. They end up using an RDBMS as nothing more than a dumb bit bucket -- often hidden behind increasingly complex abstractions. The NoSQL movement, unintentionally, lets these programmers feel superior about their lack of knowledge. I don't want to argue against the legitimate use of NoSQL solutions. I just don't think there are enough use-cases to justify the hype. For example, an article was posted here last week about using NoSQL solution to store e-commerce orders.

gte910h 17y ago
I disagree. Lots of applications only require dumb bit buckets. There is no real sophistication or structure to the data. Anything more is over engineering for a large majority of products which data storage is not particularly useful or meaningful.
- bphogan 17y ago
  I worked on a system a couple of years ago where we ran calculations nightly and then we write the results of this calculation to a row in a table for caching purposes. This row was then fetched by another job to generate a PDF. We used SQL for this because Reporting Services could build a pdf from a row in a table. It's not a good solution. This type of data doesn't need to be searchable. It's using a database server as a caching mechanism. That seems wrong. Seems like memcached, mongo, couch, or anything else would have been better. Heck, people have been using memcached for a long time, and yet all of a sudden people don't see a use for NoSQL setups? Are we sure we're not just doing the same old "Defend what you know" dance?

lucifer 17y ago

"SVN vs Git" An excellent comparative case in point that in my opinion actually undercuts what you are asserting. You do not lose features and functionality in that transition (where as noSQL is by design reductive), and further, Git is a replacement for SVN and not a complementary tool.

bphogan 17y ago
Actually you do lose functionality by going that way. SVN handles binaries better. I can also cherry-pick files from a directory structure, so if I need to fetch out a subfolder or an individual file, I can do so. With Git I must clone the repo or set up a web service so I can get access to the file system. But they're different tools for different audiences. In my environment, I do use both of these tools together. The lesson Git, Ruby, Subversion, Apache, and many other projects have taught me is that instead of saying "What I have is fine, I don't need what you have", I need to ask "Why do you use what you use, why does it help you, and how might it help me?