# Database Schema - Migration Implementation

## ADDED Requirements

### Requirement: Date/time column types

The system SHALL use DATETIME2(7) for all date/time columns instead of legacy DATETIME.

#### Rationale

- DATETIME2(7) provides nanosecond precision vs millisecond for DATETIME
- Larger date range (0001-01-01 to 9999-12-31)
- Recommended for all new SQL Server development
- Compatible with .NET DateTimeOffset

#### Affected Tables

All tables with date/time columns:
- Search (SubmitDT, StartDT, EndDT)
- DataUpdate (UpdateDT)
- WorkOrder_Curr/Hist (various date columns)
- WorkOrderStep_Curr/Hist (LastUpdateDT)
- WorkOrderTime_Curr/Hist (GlDate, LastUpdateDT)
- And all other tables with DATETIME columns

#### Scenario: Date precision preserved

- **WHEN** a datetime value is stored with sub-millisecond precision
- **THEN** the full precision is preserved in DATETIME2(7) columns

## ADDED Requirements

### Requirement: DbUp migration scripts

The system SHALL use DbUp migration scripts to create and maintain the database schema.

#### Migration Script Organization

- Scripts SHALL be numbered sequentially (NNN_Description.sql)
- Scripts SHALL be embedded as resources in JdeScoping.Database assembly
- Scripts SHALL execute in dependency order (tables → views → types → procedures)

#### Script Numbering Ranges

| Range | Category |
|-------|----------|
| 001-025 | Tables |
| 026-032 | Views |
| 033-039 | Table-valued parameter types |
| 040-043 | Stored procedures |
| 044+ | Functions |

#### Scenario: Fresh database deployment

- **WHEN** the application starts against an empty database
- **THEN** DbUp creates all 44 database objects in dependency order
- **AND** the SchemaVersions table records each applied migration

#### Scenario: Incremental migration

- **WHEN** the application starts against a database with some migrations applied
- **THEN** DbUp applies only new migrations not in SchemaVersions
- **AND** existing data is preserved

### Requirement: Migration idempotency

The system SHALL ensure migration scripts are idempotent for safe re-execution.

#### Idempotency Patterns

- Tables: Use `IF NOT EXISTS` checks
- Views: Use `CREATE OR ALTER VIEW`
- Types: Check sys.types before creation
- Procedures: Use `CREATE OR ALTER PROCEDURE`
- Functions: Use `CREATE OR ALTER FUNCTION`

#### Scenario: Re-run migration on existing database

- **WHEN** a migration script runs against a database where the object already exists
- **THEN** the script completes without error
- **AND** the object definition matches the script