diff options
| -rw-r--r-- | _posts/2020-08-31-the-database-i-wish-i-had.md | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/_posts/2020-08-31-the-database-i-wish-i-had.md b/_posts/2020-08-31-the-database-i-wish-i-had.md index f16cd38..2b57aae 100644 --- a/_posts/2020-08-31-the-database-i-wish-i-had.md +++ b/_posts/2020-08-31-the-database-i-wish-i-had.md @@ -80,12 +80,12 @@ that would have to be emulated~~[^posix-sqlite]. That's not to say that adding an IndexedDB compatibility layer to SQLite would be enough to make it fit the other requirements I mention on this - page. SQLite still is an implementation of a relational, SQL, table-oriented - database. It is probably true that cherry-picking the relevant parts of - SQLite (like storage access, consistency, crash recovery, parser generator, - etc.) and leaving out the unwanted parts (SQL, tables, FTS, etc.) would be - better than including the full SQLite stack, but that's simply an - optimization. Both could even coexist, if desired. + page. SQLite still is an implementation of a update-in-place, SQL, + table-oriented database. It is probably true that cherry-picking the + relevant parts of SQLite (like storage access, consistency, crash recovery, + parser generator, etc.) and leaving out the unwanted parts (SQL, tables, + threading, etc.) would be better than including the full SQLite stack, but + that's simply an optimization. Both could even coexist, if desired. SQLite would have to be treated similarly to how Datomic treats SQL databases: instead of having a table for each entities, spread attributes |