5 ms·

> find the barriers to entry on NoSQL lower Not having to think rigorously about the logical structure of your data is a huge selling point for many. For progr

> find the barriers to entry on NoSQL lower Not having to think rigorously about the logical structure of your data is a huge selling point for many. For programmers, because it means they don't have to think. And for employers, because it means they can make do with programmers who don't want to think.

20years 10y ago
That is a scary thought.
- pbreit 10y ago
  Only scary if you are locked into the past and/or closed-minded. (disclaimer: I'm not a mongo fan).
  - 20years 10y ago
    I was mainly referring to "And for employers, because it means they can make do with programmers who don't want to think." Sorry, but I don't want to work in an environment where programmers don't want to think or don't have to think. That is a scary thought. Has nothing to do with being locked into the past or being closed-minded. Just the opposite actually.
    - emp_zealoth 10y ago
      How else do you think we arrived at webpages that need hundreds of MB of RAM?
- catnaroek 10y ago
  It isn't that scary once you take into account the fact that our brains are just as finite as any other resource available to us. It's a virtue not to make more mental effort than what is strictly necessary to complete the task at hand.
  - 20years 10y ago
    I agree with "It's a virtue not to make more mental effort than what is strictly necessary." but to have an environment with only "programmers who don't want to think" is not appealing at all to me. I personally want to be surrounding by thinkers.
sangnoir 10y ago
> Not having to think rigorously about the logical structure of your data is a huge selling point for many I'll play the devils advocate: what ever logical structure of the data you come up with will not line-up with relational DB tables - I have had the pleasure of designing relational schemas for cyclic graphs. Hell, we have been trying and failing to do Object-Relational Mapping for years now, and it's still a shit-show. I could name a long list of ORM libraries and an even longer list of their various deficiencies. Say you've thought rigorously about the logical structure of your data and v1 is out, and now a change comes along and you need an extra field or 5. Renormalize your structure, write some migration scripts (in both directions, just in case you want to downgrade). With NoSQL I'll just dump the new document structure and call it a day (or rather, deal wiht the differences in the application layer).
- catnaroek 10y ago
  I suspect you read too much into my comment. I wasn't making a value judgment. If anything, I'm actually in favor of thinking no more than necessary to get high-quality results - but also no less than that. > I'll play the devils advocate: what ever logical structure of the data you come up with will not line-up with relational DB tables That contradicts my experience. The relational model isn't a panacea, but it lets me model most scenarios adequately. Whenever the relational model is deficient, what I want is more powerful schemas (sum and product tables, constraints spanning several tables, etc.), not less. > Hell, we have been trying and failing to do Object-Relational Mapping for years now, and it's still a shit-show. I'm inclined to think the problem is actually at the object-oriented end of the bridge: https://news.ycombinator.com/item?id=11861520 https://news.ycombinator.com/item?id=11861520 > With NoSQL I'll just dump the new document structure and call it a day (or rather, deal with the differences in the application layer). Correctly managing these differences without help from schema-aware tools is rather painful.

20years 10y ago

That is a scary thought.

pbreit 10y ago
Only scary if you are locked into the past and/or closed-minded. (disclaimer: I'm not a mongo fan).
- 20years 10y ago
  I was mainly referring to "And for employers, because it means they can make do with programmers who don't want to think." Sorry, but I don't want to work in an environment where programmers don't want to think or don't have to think. That is a scary thought. Has nothing to do with being locked into the past or being closed-minded. Just the opposite actually.
  - emp_zealoth 10y ago
    How else do you think we arrived at webpages that need hundreds of MB of RAM?
catnaroek 10y ago
It isn't that scary once you take into account the fact that our brains are just as finite as any other resource available to us. It's a virtue not to make more mental effort than what is strictly necessary to complete the task at hand.
- 20years 10y ago
  I agree with "It's a virtue not to make more mental effort than what is strictly necessary." but to have an environment with only "programmers who don't want to think" is not appealing at all to me. I personally want to be surrounding by thinkers.

sangnoir 10y ago

> Not having to think rigorously about the logical structure of your data is a huge selling point for many I'll play the devils advocate: what ever logical structure of the data you come up with will not line-up with relational DB tables - I have had the pleasure of designing relational schemas for cyclic graphs. Hell, we have been trying and failing to do Object-Relational Mapping for years now, and it's still a shit-show. I could name a long list of ORM libraries and an even longer list of their various deficiencies. Say you've thought rigorously about the logical structure of your data and v1 is out, and now a change comes along and you need an extra field or 5. Renormalize your structure, write some migration scripts (in both directions, just in case you want to downgrade). With NoSQL I'll just dump the new document structure and call it a day (or rather, deal wiht the differences in the application layer).

catnaroek 10y ago
I suspect you read too much into my comment. I wasn't making a value judgment. If anything, I'm actually in favor of thinking no more than necessary to get high-quality results - but also no less than that. > I'll play the devils advocate: what ever logical structure of the data you come up with will not line-up with relational DB tables That contradicts my experience. The relational model isn't a panacea, but it lets me model most scenarios adequately. Whenever the relational model is deficient, what I want is more powerful schemas (sum and product tables, constraints spanning several tables, etc.), not less. > Hell, we have been trying and failing to do Object-Relational Mapping for years now, and it's still a shit-show. I'm inclined to think the problem is actually at the object-oriented end of the bridge: https://news.ycombinator.com/item?id=11861520 https://news.ycombinator.com/item?id=11861520 > With NoSQL I'll just dump the new document structure and call it a day (or rather, deal with the differences in the application layer). Correctly managing these differences without help from schema-aware tools is rather painful.