73849b40a8
- Introduced MQTTPublishRequest and MQTTPublishResponse models for handling MQTT message publishing. - Implemented a new POST route for publishing MQTT messages, including error handling and logging. - Enhanced the StandaloneAutoRecorder with improved logging during manual recording start. - Updated the frontend to include an MQTT Debug Panel for better monitoring and debugging capabilities.
95 lines
3.4 KiB
Markdown
95 lines
3.4 KiB
Markdown
# Database Design Recommendation Summary
|
|
|
|
## Critical Issue Identified
|
|
|
|
Your current design has a **fundamental flaw** that prevents it from working correctly with repetitions:
|
|
|
|
### The Problem
|
|
|
|
The phase tables (`soaking`, `airdrying`, `cracking`, `shelling`) have this constraint:
|
|
```sql
|
|
CONSTRAINT unique_soaking_per_experiment UNIQUE (experiment_id)
|
|
```
|
|
|
|
This means you can **only have ONE soaking record per experiment**, even if you have 3 repetitions! This breaks your entire repetition system.
|
|
|
|
### Why This Happens
|
|
|
|
When you create an experiment with 3 repetitions:
|
|
1. ✅ 3 rows are created in `experiment_repetitions`
|
|
2. ❌ But you can only create 1 row in `soaking` (due to UNIQUE constraint)
|
|
3. ❌ The other 2 repetitions cannot have soaking data!
|
|
|
|
## Design Assessment
|
|
|
|
### Current Approach: Separate Tables (❌ Not Recommended)
|
|
|
|
**Problems:**
|
|
- ❌ UNIQUE constraint breaks repetitions
|
|
- ❌ Schema duplication (same structure 4 times)
|
|
- ❌ Hard to query "all phases for a repetition"
|
|
- ❌ Sequential timing calculations are complex and error-prone
|
|
- ❌ No automatic phase creation when repetitions are created
|
|
|
|
### Recommended Approach: Unified Table (✅ Best Practice)
|
|
|
|
**Benefits:**
|
|
- ✅ Properly supports repetitions (one phase per repetition)
|
|
- ✅ Automatic phase creation via database trigger
|
|
- ✅ Simple sequential time calculations
|
|
- ✅ Easy to query all phases for a repetition
|
|
- ✅ Single source of truth
|
|
- ✅ Easier to maintain and extend
|
|
|
|
## Recommended Solution
|
|
|
|
I've created a migration file that implements a **unified `experiment_phase_executions` table**:
|
|
|
|
### Key Features:
|
|
|
|
1. **Single Table for All Phases**
|
|
- Uses `phase_type` enum to distinguish phases
|
|
- One row per phase per repetition
|
|
- Proper UNIQUE constraint: `(repetition_id, phase_type)`
|
|
|
|
2. **Automatic Phase Creation**
|
|
- Database trigger automatically creates phase executions when a repetition is created
|
|
- Based on the experiment's phase configuration (`has_soaking`, `has_airdrying`, etc.)
|
|
|
|
3. **Automatic Sequential Timing**
|
|
- Database trigger calculates sequential start times
|
|
- If soaking ends at 5pm, airdrying automatically starts at 5pm
|
|
- If airdrying ends at 5:12pm, cracking automatically starts at 5:12pm
|
|
|
|
4. **Backward Compatibility Views**
|
|
- Views created for `soaking_view`, `airdrying_view`, etc.
|
|
- Existing code can continue to work (with minor updates)
|
|
|
|
## Files Created
|
|
|
|
1. **`docs/database_design_analysis.md`** - Detailed analysis with comparison matrix
|
|
2. **`management-dashboard-web-app/supabase/migrations/00012_unified_phase_executions.sql`** - Complete migration implementation
|
|
|
|
## Migration Path
|
|
|
|
1. Review the analysis document
|
|
2. Test the migration on a development database
|
|
3. Update application code to use the new table structure
|
|
4. Migrate existing data (if any)
|
|
5. Drop old phase tables after verification
|
|
|
|
## Alternative: Fix Current Design
|
|
|
|
If you prefer to keep separate tables, you MUST:
|
|
1. Remove `UNIQUE (experiment_id)` constraints from all phase tables
|
|
2. Keep only `UNIQUE (repetition_id)` constraints
|
|
3. Add trigger to auto-create phase entries when repetitions are created
|
|
4. Fix sequential timing calculations to use `repetition_id` instead of `experiment_id`
|
|
|
|
However, this still has the drawbacks of schema duplication and complexity.
|
|
|
|
## Recommendation
|
|
|
|
**Use the unified table approach** - it's cleaner, more maintainable, and properly supports your repetition model.
|
|
|