From c7498c8b05b96e90cd27359e1587f8bdab55ebd9 Mon Sep 17 00:00:00 2001 From: Richard Newman Date: Tue, 17 Jan 2017 11:00:29 -0800 Subject: [PATCH] Add some motivations that were living in one of rnewman's docs. --- Thoughts:-motivations,-what-it's-not.md | 24 ++++++++++++++++++++++++ Thoughts:-what-it's-not.md | 11 ----------- 2 files changed, 24 insertions(+), 11 deletions(-) create mode 100644 Thoughts:-motivations,-what-it's-not.md delete mode 100644 Thoughts:-what-it's-not.md diff --git a/Thoughts:-motivations,-what-it's-not.md b/Thoughts:-motivations,-what-it's-not.md new file mode 100644 index 0000000..361d6b8 --- /dev/null +++ b/Thoughts:-motivations,-what-it's-not.md @@ -0,0 +1,24 @@ +## Motivations + +Project Mentat is specifically intended to address deficiencies in existing embedded storage systems: + +- Schema evolution is fiddly and error-prone, but it's a frequent event because schemas change alongside product features. +- Schema and data sharing between modules is risky and difficult. (_E.g._, Feature A depends on Feature B's schema, and will break — perhaps undetectably — if it changes.) +- Unit schema/data ownership — that each database holds one module's data, and has one schema, and is managed by a single domain-specific code module — makes it unnatural to combine data across modules. We can't arbitrarily encrypt your bookmarks like we can your passwords. We can't query for sites in your history that have saved passwords in the login manager, _etc._ +- Traditional single-schema systems (as opposed to CQRS) don't cope well with tensions between writers and different readers. _E.g._, storing frecency in-line with history makes Places hard to change and limits possible approaches to improve performance. Event-shaped data is a powerful concept, but existing approaches require developers to do all the work, so they don’t. +- Join-heavy queries are extremely hard to write correctly in SQL. (Non-SQL alternatives have their own problems around scaling, querying, durability, and concurrent access.) +- Full-text indexing is inconvenient and requires specialized knowledge. +- Change observing is an afterthought, either through Gecko notifications driven by API code itself, or having to be expressed as database triggers written by 'wizards', which are unable to have side-effects outside of the database. +- Syncing and data replication are ignored, or ad hoc domain-specific versions are built after the fact. + +In short: if you start with SQLite and try to solve schema sharing, easy FTS, add some helpers for CQRS, and the rest, you end up building a hacky version of Mentat. + + +## What it's not + +- Not SQL. Queries and data are expressed via data structures. +- Not an ORM. Data and results are data-shaped, not object-shaped. +- Not just a graph store. Queries aren't expressed through paths, though paths can be part of them. +- Not a document store. +- Not NoSQL. Rich queries, rich types. +- Not schemaless. Schemas are an important part of thinking about a domain and characterizing storage and querying. \ No newline at end of file diff --git a/Thoughts:-what-it's-not.md b/Thoughts:-what-it's-not.md deleted file mode 100644 index f84dddc..0000000 --- a/Thoughts:-what-it's-not.md +++ /dev/null @@ -1,11 +0,0 @@ -Not SQL. Queries and data are expressed via data structures. - -Not an ORM. Data and results are data-shaped, not object-shaped. - -Not just a graph store. Queries aren't expressed through paths, though paths can be part of them. - -Not a document store. - -Not NoSQL. Rich queries, rich types. - -Not schemaless. Schemas are an important part of thinking about a domain and characterizing storage and querying. \ No newline at end of file