[hardwaresofton]

Generally, if you have a relatively large chunks of non-relational data, you can use a document store.

I could imagine the data model for superheroes being a fit for documents - information on one super hero is not tightly coupled to another super hero. Sure you could normalize some of the abilities and what not, but the main chunk that you'll be searching by/storing is a Super Hero (or whatever you want to call that object).

Also, note that document stores support somethings that you would consider relational (ex. RethinkDB supports joins), so the lines are becoming blurred these days.

[jawngee]

But what happens when you want to start associating them on when they appeared together or fought each other? What about the different iterations of an individual character in different continuities? (Captain America was like six different dudes right?)

I think a document store is the worst way to store this kind of stuff.

imho, ymmv.

[hardwaresofton]

What you've brought up is precisely where relational databases excel -- it's a tradeoff (as anything else, you have to decide when to use one or the other). How many relationships do you have/expect? How intermingled/related is your data? If the answer is "not much" , then maybe you should go with documents, if it's high maybe you should go with RDBMS.

Also, the lines are blurred, like I previously stated: - RethinkDB does joins - Postgres has good support for storing JSON documents

[calpaterson]

In reality, almost all interesting data has relationships. Even a two dimensional graph is expressing a relationship (and hopefully a correlation) between two sets of data.

I think whether or not there are relationships is the wrong way to consider the question of document vs relational. I think of a relational schema as a canonical way to store your data so that you can easily and efficiently project it in multiple different ways (queries).

A document schema stores your data as one possible projection of that data. Obviously you're right that if you can know for sure that one particular projection is the vast majority of queries then this is fine. The problem is that you have to be right about which projection of your data is most important, and normally before you write any code.

In my experience, for greenfield projects it's surprisingly hard to predict what kinds of projections are most important. Often what is interesting to users changes, or you didn't quite have the right projection or whatever.

To compound this, a lot of document stores often don't have good schema migration tools. Migrating schemas and data is actually a lot easier with SQL than anywhere else. Postgres can migrate the schema and the data transactionally and you can rollback if there is a problem in any of the steps. They are also type checked.

Basically, when starting a new project, you are probably better off doing a relational model of your data than anything else. Later, when you know your data access patterns, you can change to a document store and get the various benefits of them without the tradeoffs

[hardwaresofton]

Agree that how you plan to project the data is certainly important (SQL offers immense flexibility, assuming you're heavily normalized). But still, the point stands that you can use some document stores relationally. This makes this point a little duller.

Also, document stores' migration tools are the supported languages themselves... The only migration tool you need is a function from one document to another. RethinkDB actually supports almost arbitrary function input. Also, migrations are a little less important when it comes to document stores because a lot of the schema validation logic gets moved up one level (to the middle layer).

I strongly disagree about which one to start with. One of the biggest widely-noted benefits of a document store is that you don't have to think of your schema up front, you don't have to maintain constantly changing schema declarations, etc. Did you mix up the terms them by accident?

If you didn't mix them up, here's a concrete example of why document stores are often better to start with:

- I'm writing a chat service

- I am thinking about the message model, and decide a message has three fields, a message, sender, and timestamp.

- Three minutes later, while building the service, I realize that I also want to track the origin of the message (through some geolocation service or something), or the locale.

If I had used a relational database, I'd have to edit the schema, re-up/re-migrate the database, etc, when in a document store, I could just go on using it like the locale was there (and maybe add one line of code adding some default/null value for locale if it wasn't on objects I read from the database)

[jdmichal]

> What about the different iterations of an individual character in different continuities?

This has nothing to do with document vs relational data stores, and everything to do with natural vs surrogate keys.

[hardwaresofton]

Not sure if this is quite right... If you decided to add a "continuity" field that denoted which continuity a character was from, you'd probably want to use that data to relate characters -- in SQL land that would usually be a foreign key, in document stores, it's a little less clear how to do it (depending on which you pick) -- RethinkDB does (equi)joins, so you could just use a string. Can't say the same for other relational databases, I think the query would turn into a MapReduce.