You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: MP Mock Database.md
+6-4Lines changed: 6 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -6,7 +6,7 @@ parent: Materialized Paths
6
6
permalink: /mat-paths/mock-database
7
7
---
8
8
9
-
Materialized paths (MPs) model is one of several approaches to storing a tree structure in a relational database (for details, please see [References](../design-rules#TreesAndRDBMS)). This project focuses on developing SQL/SQLite scripts for performing various MPs operations using this [mock SQLite database][].
9
+
Materialized paths (MPs) model is one of several approaches to storing a tree structure in a relational database (for details, please see [References][TreesAndRDBMS]). This project focuses on developing SQL/SQLite scripts for performing various MPs operations using this [mock SQLite database][].
10
10
11
11
### Schema
12
12
@@ -60,13 +60,13 @@ This table contains three independent and two stored generated columns. The form
60
60
61
61
The category name should preferably include alphanumeric characters only. Other characters may cause problems; slashes, comma, and double quote are prohibited (see the CHECK constraint). Names starting with the tilde character are reserved for internal use.
62
62
63
-
There are several [approaches](../design-rules#TreesAndRDBMS) to encoding the *prefix* value based on an FS-like path using node names or IDs. With fixed length IDs, the path separator is unnecessary. For example, 8-character ASCII IDs and delimiterless VARCHAR(255) (where available) may encode a hierarchy with up to 32 levels. The current implementation uses plain FS-like paths with the forward slash as the path separator. All prefixes are absolute and include trailing but not leading slash to simplify code. Top-level nodes have the blank string as their prefix.
63
+
There are several [approaches][TreesAndRDBMS] to encoding the *prefix* value based on an FS-like path using node names or IDs. With fixed length IDs, the path separator is unnecessary. For example, 8-character ASCII IDs and delimiterless VARCHAR(255) (where available) may encode a hierarchy with up to 32 levels. The current implementation uses plain FS-like paths with the forward slash as the path separator. All prefixes are absolute and include trailing but not leading slash to simplify code. Top-level nodes have the blank string as their prefix.
64
64
65
-
The *ascii_id* column is a random eight-character long string, which may contain alphanumeric ASCII characters, dash, and underscore (the last two characters bring the alphabet size to 2^6 characters). This column encodes a 64-bit number generated from the *id* column. In practice, however, the process is the [opposite](../../patterns/ascii-id). The ID-based prefix encoding may use this column in the future.
65
+
The *ascii_id* column is a random eight-character long string, which may contain alphanumeric ASCII characters, dash, and underscore (the last two characters bring the alphabet size to 2^6 characters). This column encodes a 64-bit number generated from the *id* column. In practice, however, the process is the [opposite](../patterns/ascii-id). The ID-based prefix encoding may use this column in the future.
66
66
67
67
The *path* column (generated from *prefix* and *name*) is the reference target of the foreign key from the *files_categories* table. This deliberate deviation from the more natural *id* or *ascii_id* targets simplifies several operations.
68
68
69
-
By definition, the employed MPs model fulfills [design **Rule #1**](../design-rules#Rules). The generated *path* column implements **Rule #3**, and the unique constraint enforces **Rule #5**. By design, each category can have only a single parent reference via the *prefix* column, which defines its parent's *path*, enforcing **Rule #2**. **Rule #4** is semantic and not subject to database controls. *name*/*prefix*/*path* collations enforce **Rule #6**. Many-to-many item-category relation tables implement **Rule #7**, and the separation of tables for categories and items ensures **Rule #8**. The CHECK constraint on the *name* column ensures the absence of the most troublesome characters in the values.
69
+
By definition, the employed MPs model fulfills [design **Rule #1**](./design-rules#Rules). The generated *path* column implements **Rule #3**, and the unique constraint enforces **Rule #5**. By design, each category can have only a single parent reference via the *prefix* column, which defines its parent's *path*, enforcing **Rule #2**. **Rule #4** is semantic and not subject to database controls. *name*/*prefix*/*path* collations enforce **Rule #6**. Many-to-many item-category relation tables implement **Rule #7**, and the separation of tables for categories and items ensures **Rule #8**. The CHECK constraint on the *name* column ensures the absence of the most troublesome characters in the values.
70
70
71
71
The last constraint is a self-referential foreign key *prefix*→*path* to the parent category. For now, both UPDATE and DELETE cascades are disabled. These cascades are only usable for basic scenarios and should not be relied upon in general.
72
72
@@ -103,4 +103,6 @@ As discussed later, the delete category operation moves the target subtree to th
0 commit comments