Contested topic, обсуждалось на 1:1 2026-03-20, не приоритет сейчас. Обе позиции имеют merit; компромисс не достигнут.
Контекст
LOINC mappings в production имеют override mechanism — ручное исправление маппинга когда automatic результат неправилен. Каждый override несёт reasoning (кто и почему исправил) для аудита.
Текущая реализация (Артур): отдельная таблица mapping_overrides с active/inactive флагами через supersede. При исправлении старая запись помечается inactive, новая active. Reasoning обязателен.
Возникает question: нужны ли две отдельные таблицы (input_mappings + mapping_overrides) когда обе имеют одинаковую структуру (active/inactive + reasoning)?
Позиции
A. Отдельная таблица mapping_overrides (Артур)
За:
- Sort быстрее без миллионов записей в одной таблице
- Override — доминирующий приоритет, явное разделение делает это очевидным семантически
- Отдельная семантика “это исправление вручную” vs “это auto-generated mapping”
Против:
- Дублирование схемы (active/inactive логика в обеих)
- Lookup усложняется (надо проверять две таблицы)
B. Единая таблица с историей (Ильдар)
За:
- Унификация схемы — одна таблица, одна active/inactive логика
- Сортировка по дате создания → последняя active = current
- Концептуально override = “следующий шаг evolution маппинга”
- Меньше duplication, меньше сюрпризов
Против:
- Sort по миллионам записей дороже
- Семантика “ручное исправление” теряется в общем потоке
- Override приоритет не такой явный
Что нужно для разрешения
- Performance benchmark на реальных миллионах записей (sort timing на единой vs lookup в двух)
- Решение по Lookup priority — нужна ли отдельная “fast path для overrides” логика
- Volume reality check — как часто overrides реально создаются (если редко, объединение дешевле; если регулярно, разделение оправданно)
Связано
- loinc-unification-direction — parent topic
- dictionary-first-paradigm — related (override = часть Dictionary management)
- loinc-harmonization-service — текущий host обеих таблиц
Источники
Источники: 1.