diff options
| -rw-r--r-- | _posts/2020-08-31-the-database-i-wish-i-had.md | 14 |
1 files changed, 7 insertions, 7 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 4ba1885..73423ce 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 @@ -83,20 +83,20 @@ that would have to be emulated~~[^posix-sqlite]. 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 using of all it just to building on top of the whole SQLite - stack, but that's simply an optimization. Both could even coexist, if - desired. + 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. SQLite would have to be treated similarly to how Datomic treats SQL databases: instead of having a table for each entities, spread attributes over the tables, etc., it treats SQL databases as a key-value storage so it - doesn't have to re-implement interacting with the disk. + doesn't have to re-implement interacting with the disk that other databases + do well. The tables would contain blocks of binary data, so there isn't a difference on how the SQLite storage backend behaves and how the IndexedDB storage - backend behaves, much like Datomic works the same regardless of the storage - backend, same for PouchDB. + backend behaves, much like how Datomic works the same regardless of the + storage backend, same for PouchDB. I welcome corrections on what I said above, too. |