XTDB in particular is not just a document DB. But if you're interested specifically in a document DB vs a relational DB comparison, then two things come to mind where a document DB makes more sense: • You store, well, documents. If there are relationships, they're mostly bound to be within a particular document • (This assumes open schema or a lack of schema) You need to store all possible data that comes in, even if it doesn't adhere to some well known shape

https://martinfowler.com/articles/bitemporal-history.html

That focuses on a different aspect, one that most document DBs don't have (but XTDB does).

An example of a "document" may be "events" in an event sourcing system. You could store events in a rdbms, but events are so wildly different in their content that the best you could do for that table is to have columns for what's effectively metadata, and a column for a blob that's the event itself. The events aren't really "relational data", but they are something you'd want to be able to search for efficiently (and not just search against metadata columns, but also data in the blob). Document databases help you index and search data like this.

Granted, I think postgres has some bells and whistles for storing and efficiently searching JSON data, but that's not really the main feature or point of using an rdbms

Another example of documents: I work with weather data that's generally passed around in XML documents. Each effectively represents some meteorological object of interest: a cold front, an area of heavy snowfall, an area of high winds. Effectively, each of these documents follows a pretty loose schema: they all have a geometry and a bag of attributes. You'd want to be able to search efficiently (find me all the winds over 100km/h), but it would be kind of weird to try and model tables for every possible type of object. So again you either have blobs you need to store and inspect, or you use a document db which is built for that kind of thing.

https://youtu.be/Cym4TZwTCNU?si=iEekHd67h6bRHete I think Rich Hickey's talk "Deconstructing the Database" gives a great overview of what something like Datomic or XTDB offers over a conventional SQL DB.

> it would be kind of weird to try and model tables for every possible type of object IMO this is the biggest legitimate reason why people opt for a document-oriented DBMS. Comprehensive relational modelling can be overkill in many problem domains. "web scale" and the sacrifice of ACID / joins is a more subtle and secondary conversation. Popular SQL databases like Postgres/SQLite use row-oriented storage that really shines when you have a good upfront understanding of the schema and can feasibly normalize it to 3NF. Conversely these systems often lack good nested data support (JSONB is really just a workaround) and row-orientation makes naively storing very wide & sparse tables (with lots of NULLs) problematic. Any DBMS that claims to be document-oriented is mostly just saying it works well for handling heavily denormalized/nested/opaque/sparse structures.

https://tonsky.me/blog/datascript-internals/

^ complements "Deconstructing the Database"

Thanks for your responses everyone. I don't understand why Datomic is being mentioned, I didn't think it was a document DB?

We got carried away

Phew, for a moment I thought I was way off base with what Clojure-y DBs were up to

I’m interested in this thread too because my… friend’s agency is still addicted to paper and fax machines and handwritten signatures of questionable authenticity. I would love for… my friend’s administrative forms etc to be in a suitable database not a file cabinet, but I would need (a miracle and) a way to bridge the workflow gap in the face of extreme institutional resistance.

My experience was the complete opposite of what others mentioned - I tried PostgreSQL's JSONB format and I honestly was blown away - it sure is not ideal if you need to store, for example, dates in a JSON, but it's not that bad either - it's easy to make custom indexes for some semi-structured fields that you know they'll be always present, and you have queries to make row-based document-based, and back.

SQL is clumsy, hard to read and write, but is honestly way better than any alternative that I know of

In which case, it would be good to have some sort of "learning timeline" similar to how we all went through grade school and then through higher learning, there's a sequence. I think we could perhaps figure out an optimal learning sequence for Clojure [when coming from Von Neumann Style langs]. What say thee

#C02CPM2R1KK and #C053AK3F9 may be the best audiences for that idea.

I would suggest leaning into the extreme nonlinearity of this particular tree of knowledge.

You could design a curriculum or tutorial

There is a need for more tutorials geared towards students and windows users

https://blog.michielborkent.nl/aws-lambda-nbb.html this blog post is an example of the sort of things that I think beginners need more of

Cool.

Yeah. hmm

When I started with Clojure, I wrote to #C053AK3F9 about my experience. My biggest problem was that the best training materials were not up-to-date. Some things were deprecated and replaced by other recommendations. I kept asking my brainwasher (the one who sold me on Clojure) about the up-to-date version of the stuff.

Makes sense. I was working on doing some screen recordings I think those can be helpful

A smooth path to learning Clojure for people on Windows would certainly help. I've been interested in learning Clojure, and it's kind of crazy how even getting started with Rust on Windows is a push of 2 buttons, and installing Clojure is a 2 week maze on Windows and even the final result has some bizarre gotchas none of the tutorials cover - like having to double-double quote things in the command line etc. It also seemed like Clojure promoted simplicity and less need for libraries, but then every tutorial used a totally different build tool like deps.edn, lein, boot etc and it always felt like whatever the modern one I should be using was kind of out of reach. I'd still love to learn it! But getting started with "modern" clojure is not a clear path is all I'm saying. For Clojurescript learning, one of the barriers is that most of the UI frameworks are built on React. So if the newbie doesn't yet know React, they've first got to go learn that, and then I think many just stay.

The easiest way to get started on windows is to get vscose and calva and then do ‘start a standalone REPL (not in project)’

"a two week maze" :rolling_on_the_floor_laughing:

it's true