4 ms·

I agree, Mongo is easy and fast. My problem with NoSQL is that you MUST know there won't be changing requirements: Later you might need to do the equivalent o

I agree, Mongo is easy and fast. My problem with NoSQL is that you MUST know there won't be changing requirements: Later you might need to do the equivalent of joining 3-4 tables. Then you have trouble... But I'm a coward that look both left and right before crossing a street.

threeseed 12y ago
MongoDB is actually well suited to changing requirements. Because it is schema less and document based you can trivially add new rich schemas to existing documents. And in the case of doing joins you can always do it in application layer or using DBRef or MapReduce. There are valid options that are still quite performant.
- nebstrebor 12y ago
  "Because it is schema less ... you can trivially add new rich schemas" made me lol. Maybe this makes sense to Mongo users, but I have no idea what you mean here and the language you use to describe this feature is, well, contradictory to say the least.
  - threeseed 12y ago
    Actually it does seem contradictory reading back on it. I meant it doesn't have a fixed, enforced schema like SQL databases and it is easy to add new data structures e.g. lists, maps, sets.
  - liveoneggs 12y ago
    it means a typo in release-15 auto-creates a whole new database without anyone noticing and you sit around and wonder where all of the data went yesterday.
    - nasalgoat 12y ago
      Oh man, the memories. Just today I enjoyed explaining to a developer why his insert into a timestamp failed because of formatting, with a nice english error message. Thanks Postgres! Whereas the same thing last year with Mongo just inserted the wrong date into a misspelled key and we didn't figure it out for days.
arethuza 12y ago
"My problem with NoSQL is that you MUST know there won't be changing requirements" I thought the main advantage of document-oriented schema-less databases (I haven't used MongoDB but I have used CouchDB) was that they are supposed to give more flexibility in the early stages of projects. NB Personally, I've moved to PostgreSQL and its JSON storage as then you get most of the benefits of both worlds.
- AlisdairO 12y ago
  > I thought the main advantage of document-oriented schema-less databases (I haven't used MongoDB but I have used CouchDB) was that they are supposed to give more flexibility in the early stages of projects. Depends on your requirements, I guess. If you want to maintain even eventual consistency, any update that crosses document boundaries has to be thought about very seriously in order to avoid breakages in the face of concurrent modifications. So, ideally you design your documents such that any one logical operation only has to hit one document. This is pretty easy for very simple tasks, but can get rapidly more difficult in the face of more complex or changing requirements. I suspect a substantial proportion of Mongo or Couch based applications simply ignore this problem, and are lucky that they don't have enough concurrent activity that stuff breaks frequently. Using Postgres/JSON neatly avoids this problem because you get ACID back, and you can do cross-document updates all you like.
- BugBrother 12y ago
  >>[NoSQL] are supposed to give more flexibility in the early stages of projects I agree with what you wrote. But my point is that _changing_ requirements can screw you, if you find that you _later_ need relational capabilities.
  - arethuza 12y ago
    Well, that's why I gave up on CouchDB once I found that I was actually much happier with the hybrid approach of using JSON documents inside a relational structure.

threeseed 12y ago

MongoDB is actually well suited to changing requirements. Because it is schema less and document based you can trivially add new rich schemas to existing documents. And in the case of doing joins you can always do it in application layer or using DBRef or MapReduce. There are valid options that are still quite performant.

nebstrebor 12y ago
"Because it is schema less ... you can trivially add new rich schemas" made me lol. Maybe this makes sense to Mongo users, but I have no idea what you mean here and the language you use to describe this feature is, well, contradictory to say the least.
- threeseed 12y ago
  Actually it does seem contradictory reading back on it. I meant it doesn't have a fixed, enforced schema like SQL databases and it is easy to add new data structures e.g. lists, maps, sets.
- liveoneggs 12y ago
  it means a typo in release-15 auto-creates a whole new database without anyone noticing and you sit around and wonder where all of the data went yesterday.
  - nasalgoat 12y ago
    Oh man, the memories. Just today I enjoyed explaining to a developer why his insert into a timestamp failed because of formatting, with a nice english error message. Thanks Postgres! Whereas the same thing last year with Mongo just inserted the wrong date into a misspelled key and we didn't figure it out for days.

arethuza 12y ago

"My problem with NoSQL is that you MUST know there won't be changing requirements" I thought the main advantage of document-oriented schema-less databases (I haven't used MongoDB but I have used CouchDB) was that they are supposed to give more flexibility in the early stages of projects. NB Personally, I've moved to PostgreSQL and its JSON storage as then you get most of the benefits of both worlds.

AlisdairO 12y ago
> I thought the main advantage of document-oriented schema-less databases (I haven't used MongoDB but I have used CouchDB) was that they are supposed to give more flexibility in the early stages of projects. Depends on your requirements, I guess. If you want to maintain even eventual consistency, any update that crosses document boundaries has to be thought about very seriously in order to avoid breakages in the face of concurrent modifications. So, ideally you design your documents such that any one logical operation only has to hit one document. This is pretty easy for very simple tasks, but can get rapidly more difficult in the face of more complex or changing requirements. I suspect a substantial proportion of Mongo or Couch based applications simply ignore this problem, and are lucky that they don't have enough concurrent activity that stuff breaks frequently. Using Postgres/JSON neatly avoids this problem because you get ACID back, and you can do cross-document updates all you like.
BugBrother 12y ago
>>[NoSQL] are supposed to give more flexibility in the early stages of projects I agree with what you wrote. But my point is that _changing_ requirements can screw you, if you find that you _later_ need relational capabilities.
- arethuza 12y ago
  Well, that's why I gave up on CouchDB once I found that I was actually much happier with the hybrid approach of using JSON documents inside a relational structure.