From 524c646cdac4153e54f2163e280176adbc4873fa Mon Sep 17 00:00:00 2001 From: EuAndreh Date: Thu, 3 Sep 2020 22:08:56 -0300 Subject: db post: better pinpoint sqlite unsuitability --- _posts/2020-08-31-the-database-i-wish-i-had.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) (limited to '_posts') 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 -- cgit v1.2.3