https://github.com/nathanthorell/mssql-music-platform-db
Sample database in SQL Server using Flyway schema migrations
https://github.com/nathanthorell/mssql-music-platform-db
flyway sql-server sqlfluff
Last synced: about 2 months ago
JSON representation
Sample database in SQL Server using Flyway schema migrations
- Host: GitHub
- URL: https://github.com/nathanthorell/mssql-music-platform-db
- Owner: nathanthorell
- License: gpl-3.0
- Created: 2023-09-22T01:46:58.000Z (over 2 years ago)
- Default Branch: main
- Last Pushed: 2025-05-05T02:38:15.000Z (about 1 year ago)
- Last Synced: 2025-06-05T07:39:23.082Z (about 1 year ago)
- Topics: flyway, sql-server, sqlfluff
- Language: Python
- Homepage:
- Size: 37.1 KB
- Stars: 1
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Music Platform Example Database
An example database in MSSQL using Flyway for schema migrations
## Continuous Integration
### Automated SQL Quality and Migration Testing
All SQL changes are automatically validated through a comprehensive CI pipeline when pull requests are created or updated. The workflow only triggers when .sql files are modified, optimizing resource usage.
**CI Pipeline Flow:**
1. **SQL Linting** - Validates syntax and catches parsing errors with SQLFluff
1. **SQL Formatting** - Auto-formats code to maintain consistency (only if linting passes)
1. **Migration Testing** - Tests all Flyway migrations against a fresh database server container (only if SQL quality checks pass)
### Pipeline Details
#### Step 1: SQL Linting
- Runs SQLFluff lint on all changed SQL files
- **Fails fast** on syntax errors (like `FORM` instead of `FROM`)
- Prevents expensive migration testing when SQL has basic errors
- Uses the `.sqlfluff` configuration for validation rules
#### Step 2: SQL Formatting
- Auto-formats SQL files using SQLFluff to ensure consistent style
- Applies fixes for indentation, spacing, keyword casing, etc.
- **Automatically commits formatting changes** back to your branch
- Comments on PR when formatting is applied
- Only runs if linting passes successfully
#### Step 3: Migration Testing
- Spins up a fresh database server container for testing
- Creates a clean test database
- Runs all migrations in sequence using Flyway
- Validates migration integrity and consistency
- **Only runs if both SQL linting and formatting complete successfully**
### Resource Optimization
The pipeline is designed to fail fast and save CI resources:
- ❌ **Syntax errors** → Pipeline stops at linting
- ✅ **Formatting issues** → Auto-fixed, then continues to migration testing
- ✅ **Clean SQL** → Full migration testing with Docker containers
This ensures expensive database containers only spin up for valid, properly formatted SQL.
### SQL Code Formatting
SQLFluff automatically formats SQL files to maintain code consistency:
- Runs on all SQL file changes in pull requests
- Uses the `.sqlfluff` configuration in this repo
- Automatically commits formatting fixes back to your branch
- Ensures consistent code style across the team
**Bypassing SQLFluff when needed:**
In rare cases where SQLFluff's formatting is incorrect or conflicts with valid SQL patterns, you can use inline comments:
```sql
-- Ignore specific rules on a line
SELECT * FROM users; -- noqa: LT02,AL02
-- Ignore all formatting on a line
SELECT * FROM legacy_table; -- noqa
-- Ignore rules for a block of code
-- noqa:disable=LT02
SELECT *
FROM weirdly_formatted_legacy_view
WHERE complex_condition;
-- noqa:enable=LT02
-- Ignore all formatting for a block
-- noqa:disable
SELECT * FROM
some_complex_query_that_needs_special_formatting;
-- noqa:enable
```
Use these sparingly - they should be the exception, not the rule.
## Local Environment Configuration
Example of environment variables:
```bash
DB_HOST=localhost
DB_PORT=1433
DB_NAME=MusicPlatform
export FLYWAY_URL="jdbc:sqlserver://localhost:1433;databaseName=MusicPlatform;encrypt=false;trustServerCertificate=true"
export FLYWAY_USER=sa
export FLYWAY_PASSWORD=YOUR_SECRET_PASSWORD_HERE
REDGATE_DISABLE_TELEMETRY=true
```
## Create Local MSSQL Server and Database
- For local migration testing you will need a local SQL Server DB instance
- This is easy with Docker. Example:
```text
docker run -d -e ACCEPT_EULA=Y -e MSSQL_SA_PASSWORD=TestPassword01 -v mssqldata:/var/opt/mssql -p 1433:1433 --name azuresqledge mcr.microsoft.com/azure-sql-edge:latest
```
- Flyway requires a database before it can connect. To speed up this process for development iteration, I've added `create_db.zsh` which connects and checks if the database exists, if so it drops the database then creates a new empty one.
## SQL Server Naming Conventions
Below establishes standard naming for SQL Server objects.
### Tables
- Table names should be singular, representing a single row
- Don't embed data type into a name (e.g. PersonNameString)
- Avoid repeating the table name in the column definition (e.g. use Name instead of Volunteer Name in the Volunteer table)
- PascalCase (e.g. VolunteerNote)
- Tables created only to establish many-to-many relationships should simply be the names of the two tables (e.g. StudentClass)
- Example: A Student can have many Classes, and a Class can have many Students
### Views, Functions, and Procedures
These should be created as [Repeatable Migrations](https://flywaydb.org/documentation/concepts/migrations#repeatable-migrations). Follow file naming for "repeatableSqlMigrationPrefix" and "sqlMigrationSeparator".
File Naming Example:
- Views: R__schema_vw_MyView.sql
- Functions: R__schema_f_MyFunction.sql
- Procedures: R__schema_usp_MyProcedureName.sql
SQL Object Naming Example:
- Views: schema.vw_MyView
- Functions: schema.f_MyFunction
- Procedures: schema.usp_MyProcedureName
### Constraint Prefixes
- PK for primary key indexes (e.g. PK_Volunteer_VolunteerId)
- UQ for unique indexes other than primary key (UQ_TableName_ColumnName)
- IX for all other indexes (IX_TableName_ColumName)
- FK for foreign constraints (FK_TableName_ReferencedTableName_ColumnName)
- DF for Default constraints
- CK for check constraints
- CIX for clustered indexes