The 1st edition CouchDB book from 2010 explained it like this:

> We write software to improve our lives and the lives of others. Usually this involves taking some mundane information—such as contacts, invoices, or receipts—and manipulating it using a computer application. CouchDB is a great fit for common applications like this because it embraces the natural idea of evolving, self-contained documents as the very core of its data model.

> Self-Contained Data

> An invoice contains all the pertinent information about a single transaction—the seller, the buyer, the date, and a list of the items or services sold. As shown in Figure 1, “Self-contained documents”, there’s no abstract reference on this piece of paper that points to some other piece of paper with the seller’s name and address. Accountants appreciate the simplicity of having everything in one place. And given the choice, programmers appreciate that, too.

> Yet using references is exactly how we model our data in a relational database! Each invoice is stored in a table as a row that refers to other rows in other tables—one row for seller information, one for the buyer, one row for each item billed, and more rows still to describe the item details, manufacturer details, and so on and so forth.

https://guide.couchdb.org/editions/1/en/why.html

Iow, a document database stands in contrast to a relational db in that these JSON things we store in them are more stand-alone “documents” compared to storing data in rows and columns in a relational db like PostgreSQL or SQLite.

▲

SOLAR_FIELDS a day ago | parent [-]

The thing that people always miss about this takeaway is that while it is a truism, most data is actually inherently relational. Even in your example given, the individual components that are made to assemble that document are better represented as relational datastores

▲

fipar 19 hours ago | parent | next [-]

The "relational" in relational databases is not about department number in employees referencing departments.

What the model calls relations are sets of n-tuples where each attribute value has a domain.

SQL databases call their version of relations tables, and, in that view, a database with a single table is still relational.

Now I don't think SQL databases are relational but the analogy still holds (I'd just say that a relational database can have just a single relation)

If you meant it this way and I misunderstood you, apologies, though I'm not sure I'd say most data is actually inherently relational (even though I do think the relational model is the best one we have so far for databases).

However, if you meant that most data has relationships (as the ones we enforce with foreign keys in sql databases) then I agree with you, and I think using database management systems that don't have good support for representing this type of relationships between data entities will only work in niche cases and will eventually cause more trouble than benefits in general-purpose use cases.

▲

zby 12 hours ago | parent | prev | next [-]

Here is a realisation from my recent work: it is not if the data is relational - because if you need you can always push the data into relations - just like you can push it into hierarchies if all you have is files and directories. It is about how much churn there is in the relations. You can model relations with just links or something and if there is not much churn you can keep it in git and it will work OK - the problem starts when your relations start churning (like when you have reviews that need to be updated on both review instruction change and document change) this is when you see yourself start building a relational db (badly).

▲

jmalicki a day ago | parent | prev | next [-]

Nothing here says the data isn't relational. It strongly disagrees, with reasons, why it's not better represented as relational.

Personally I prefer the relational stance, and there are a lot of people who don't get it who say things like "this data isn't relational", but that's not the argument GP made.

▲

somat a day ago | parent | prev | next [-]

I would argue most data is inherently(naively?) hierarchical(the document), relational structured data is a clever but unintuitive mechanism to introduce powerful analytic opportunities to a set of data.

Basically a document is a report, a large disjoint volume of information on a subject, I consider this the natural form of data because this is how it is collected and how most people think about it. relational is sort of like storing that data as vertical slices through your stack of reports. Not natural at all but much nicer for analysis across the data set.

▲

bitwize a day ago | parent | prev [-]

In the real world of business, generally you want to store these pieces of information together to establish a historical record, not have references or links to other tables, etc. Links and relations are fragile, as anyone who's clicked through to a 404 can attest. Standalone documents last as long as the media that stores them.

	▲	sgarland a day ago \| parent [-]
		Immutable records which are retained for legal purposes should be in object storage, not a database.