31–40 of 63 posts
Is this not similar to what Simon Willison has written about before? https://sqlite-tutorial-pycon-2023.readthedocs.io/en/latest/... https://simonwillison.net/2021/Jul/28/baked-data/
Check the dates, the "before" part is inaccurate.
What I'm trying to figure out is if they're related concepts. This may be a very naive question awkwardly asked.
obviously the example is contrived, but it seems strange me that they are not storing the json in its own column - just extracting a single key from it and storing in a generated column. Why not do that in the app code if youre just going to discard the rest of the json? Here's an example i saw yesterday from mariadb, which is improving its json support in its upcoming releases. https://mariadb.com/docs/server/ha-and…
Postgres does even better and it's available right now. No virtual column needed. CREATE TABLE t1 (data JSONB); INSERT INTO t1 VALUES ('{"column1":1234}'); CREATE INDEX t1column1 ON t1(data->'column1'); SELECT * FROM t1 WHERE data1->'column1' = '1234'; // not sure about data type
Why do people say document database when they really just mean json database?
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 cor…
It would be super cool if somehow SwiftData could translate computed properties of @Model objects into these generated columns via the #Expression macro!
Earlier quoted context omitted.
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 cor…
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
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.
Why do people say document database when they really just mean json database?
But nothing prevents you from treating your relational database as a document database, set it up as a key-value store where each key is is the document title and each value is a large blob of document data. If your documents are fairly consistent it is also easy enough to build indexes and query features to regain some of the analytical ability of relational data.