4 ms·

> but it might be the right solution for many others. The author made the example of the movie database and explained why it was a good idea when they started,

> but it might be the right solution for many others. The author made the example of the movie database and explained why it was a good idea when they started, and why it didn't work out. Can you point out an example of data you would store in a document database, which is not purely for caching purposes?

corresation 13y ago
>Can you point out an example of data you would store in a document database, which is not purely for caching purposes? I've been a pretty vocal critic of document databases in the past[1] (indeed, I get a little bit of a chuckle recalling the prevailing HN wisdom a couple of years ago and comparing it to now), however I recently had a project where added data was immutable and additive and non-relational: MongoDB was the perfect choice, and provided a zero friction, easy to deploy and scale solution. [1] - http://dennisforbes.ca/index.php/2010/03/24/the-impact-of-ssds-on-database-performance-and-the-performance-paradox-of-data-explodification/ http://dennisforbes.ca/index.php/2010/03/24/the-impact-of-ss... -- this went seriously against the prevailing sentiment at the time, and there was this strong "only relics use SQL" sentiment, including here on HN.
- jonknee 13y ago
  > I recently had a project where added data was immutable and additive and non-relational: MongoDB was the perfect choice Technically that sounds a lot like the TV database example in the OP. MongoDB was the perfect choice until a feature was required that required a relation.
lotyrin 13y ago
Collecting structured log data like monitors or exception traces or user analytics. Lots of documents, no fixed schema, they're all self-contained with no relations. Map reduce makes query parallelism crazy magic. A content management system. Some stuff may want data from across relations (who owns this thing, and what is their email), but that's pretty infrequent and having nice flexible-schema documents that contain all relevant information that's being CRUD'ed simplifies things hugely - particularly in MVCC systems like Couch that put stuff like multi-master/offline-online sync and conflict resolution in the set of core expectations. Edit: That said, Postgres is also MVCC, and hstore makes schema an option the same way that relations and transactions were already, so I think it could do pretty well. I haven't gotten the chance to play with it in recent history, unfortunately.
- Govannon 13y ago
  > Some stuff may want data from across relations (who owns this thing, and what is their email), but that's pretty infrequent That might be a shaky assumption. Speaking as someone who works on a CMS, content usually has an author, and people accessing that content might be interested in them.
  - lotyrin 13y ago
    Yeah, but in most of those cases, it's as easy as get the author based on a key from his content. It's only when you want joins (e.g. give me all of the titles of all the content and their author's information at the same time) that things get hairy. Agreed it's not always going to be true for many CMSes. I meant it as a particular CMS, not the general class of CMSes but didn't make that clear at all.
- darkarmani 13y ago
  > Map reduce makes query parallelism crazy magic. Isn't that only true if you have lots of shards? Otherwise, you have one process doing the mapping.

corresation 13y ago

>Can you point out an example of data you would store in a document database, which is not purely for caching purposes? I've been a pretty vocal critic of document databases in the past[1] (indeed, I get a little bit of a chuckle recalling the prevailing HN wisdom a couple of years ago and comparing it to now), however I recently had a project where added data was immutable and additive and non-relational: MongoDB was the perfect choice, and provided a zero friction, easy to deploy and scale solution. [1] - http://dennisforbes.ca/index.php/2010/03/24/the-impact-of-ssds-on-database-performance-and-the-performance-paradox-of-data-explodification/ http://dennisforbes.ca/index.php/2010/03/24/the-impact-of-ss... -- this went seriously against the prevailing sentiment at the time, and there was this strong "only relics use SQL" sentiment, including here on HN.

jonknee 13y ago
> I recently had a project where added data was immutable and additive and non-relational: MongoDB was the perfect choice Technically that sounds a lot like the TV database example in the OP. MongoDB was the perfect choice until a feature was required that required a relation.

lotyrin 13y ago

Collecting structured log data like monitors or exception traces or user analytics. Lots of documents, no fixed schema, they're all self-contained with no relations. Map reduce makes query parallelism crazy magic. A content management system. Some stuff may want data from across relations (who owns this thing, and what is their email), but that's pretty infrequent and having nice flexible-schema documents that contain all relevant information that's being CRUD'ed simplifies things hugely - particularly in MVCC systems like Couch that put stuff like multi-master/offline-online sync and conflict resolution in the set of core expectations. Edit: That said, Postgres is also MVCC, and hstore makes schema an option the same way that relations and transactions were already, so I think it could do pretty well. I haven't gotten the chance to play with it in recent history, unfortunately.

Govannon 13y ago
> Some stuff may want data from across relations (who owns this thing, and what is their email), but that's pretty infrequent That might be a shaky assumption. Speaking as someone who works on a CMS, content usually has an author, and people accessing that content might be interested in them.
- lotyrin 13y ago
  Yeah, but in most of those cases, it's as easy as get the author based on a key from his content. It's only when you want joins (e.g. give me all of the titles of all the content and their author's information at the same time) that things get hairy. Agreed it's not always going to be true for many CMSes. I meant it as a particular CMS, not the general class of CMSes but didn't make that clear at all.
darkarmani 13y ago
> Map reduce makes query parallelism crazy magic. Isn't that only true if you have lots of shards? Otherwise, you have one process doing the mapping.