AaronPo/the-biergarten-app
1
0
Fork 0
mirror of https://github.com/aaronpo97/the-biergarten-app.git synced 2026-10-15 01:54:43 +00:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'main' into frontend/brewery-feature

Browse Source
This commit is contained in:
Aaron Po
2026-08-27 01:08:37 -04:00
parent 1254797fe1 92a30b11db
commit dab7aa2458
20 changed files with 794 additions and 627 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
docs/website/database.md
View File

@@ -6,12 +6,17 @@ convention. For the vertical-slice code that talks to this schema, see
## Schema
The full schema lives in one script:
`web/backend/Database/Database.Migrations/scripts/01-schema/schema.sql`, run by
The full schema lives under
`web/backend/Database/Database.Migrations/scripts/01-schema/`, one numbered
script per table (`01-UserAccount.sql`, `02-Photo.sql`, ...), run in order by
`Database.Migrations` (DbUp) on startup. Each table is queried directly by the
owning feature slice's repository (see
[Direct SQL via Dapper/ADO.NET](../architecture.md#direct-sql-via-dapperadonet)).
A generated DBML copy of the schema (for import into a diagramming tool such
as dbdiagram.io) lives at
`web/backend/Database/Database.Migrations/schema.dbml`.
All tables use a `UNIQUEIDENTIFIER` primary key defaulting to `NEWID()`, and
most carry a `RowVersion ROWVERSION` column used for optimistic concurrency on
updates (`UPDATE ... WHERE ... AND RowVersion = @RowVersion`).
@@ -50,10 +55,11 @@ repository or seed data yet:
**Tool**: DbUp, run by the `Database.Migrations` project/container.
Scripts live under `scripts/`, applied in order and tracked so a script never
re-runs once it has succeeded. Today that's a single `01-schema/schema.sql`.
When the schema needs to change, add a new numbered script rather than editing
`schema.sql` in place — DbUp's tracking is per-script, so editing an
already-applied script means it won't re-run against existing databases.
re-runs once it has succeeded. Today that's `01-schema/`, with one script per
table, numbered so a table's foreign keys always point at an earlier-numbered
script. When the schema needs to change, add a new numbered script rather than
editing an existing one in place — DbUp's tracking is per-script, so editing
an already-applied script means it won't re-run against existing databases.
## Data seeding