From 5983d30b16be51a5bccf6c4421391ac4a61c2739 Mon Sep 17 00:00:00 2001 From: Claudio Ortolina Date: Thu, 3 Apr 2025 10:00:55 +0100 Subject: [PATCH] Extend database documentation --- docs/database_structure.md | 25 +++++++++++++++++++++++++ 1 file changed, 25 insertions(+) diff --git a/docs/database_structure.md b/docs/database_structure.md index 97f5c065..e300faf3 100644 --- a/docs/database_structure.md +++ b/docs/database_structure.md @@ -1,5 +1,20 @@ # Database Structure + + +- [Database Structure](#database-structure) + - [Entity Relationship Diagram](#entity-relationship-diagram) + - [Tables Description](#tables-description) + - [Records](#records) + - [Records Search Index](#records-search-index) + - [Views](#views) + - [Artist Records View](#artist-records-view) + - [Triggers](#triggers) + - [Indices](#indices) + - [Notes](#notes) + - [WHY ONE TABLE?](#why-one-table) + + This document describes the database structure of the Music Library application. ## Entity Relationship Diagram @@ -119,3 +134,13 @@ The following indices are maintained for performance: - Records with `purchased_at IS NOT NULL` are in the collection - Records with `purchased_at IS NULL` are in the wishlist +## WHY ONE TABLE? + +In traditional relational database design, you would split out artists into a +separate table, and associate them with records via a join table. So why +sticking with one table? + +1. You only need to backup/export one table. +2. Re-fetching data from MusicBrainz becomes trivial, as it just needs to update one field and everything else cascades accordingly. +3. Traditional efficiency design constraints [do not apply to + SQLite](https://www.sqlite.org/np1queryprob.html), so it makes it easier to experiment with alternative database designs.