Дизайн базы данных - разные статусы для разных типов

Question

У меня есть система, которая обрабатывает задачи, и могут быть разные типы задач. Так, например, возможно, есть «исправление компьютерной задачи» и «исправление телефонной задачи». И я хочу обновить текущий статус для каждого, но поскольку это разные типы задач, они могут или не могут иметь схожий статус. Мне было интересно, какой лучший способ приблизиться к чему-то подобному.

Так для компьютерных задач, некоторые статусы могут быть:

1. Диагностирование
2. Устранение
3. Крепление
4. Полный

А потом для телефонных задач, мы будем иметь:

1. Диагностирование
2. Заказ запасных частей
3. Крепление
4. Тестирование вызовов
5. Полный

Как вы можете видеть, некоторые статусы перекрывают друг друга, в то время как некоторые из них уникальны для данного типа. Создаете ли вы новую таблицу статусов для каждого типа задачи или есть лучший способ справиться с чем-то подобным?

Answer 1

Существует более одного действительного ответа. Вот два конкурирующих подхода со своими плюсами и минусами.

Подход 1: Таблица состояний для каждого типа задачи (с колонками status_id и status_name). Это подходит, если вы также отслеживаете задачи в разных таблицах для типа задачи (например, computer_tasks_tbl и phone_tasks_tbl), так как тогда вы можете определить ограничения внешнего ключа между каждой таблицей задач и соответствующей таблицей состояний. Это преимущество заключается в том, что вы обеспечиваете целостность данных на уровне базы данных, а схема - полезная документация по дизайну. Недостаток заключается в том, что, если все чаще возникает множество задач, вы получите множество таблиц и вам придется чаще обновлять схему.

Подход 2: Единая таблица состояния для всех возможных статусов. Преимущество заключается в том, что это упрощает схему, особенно если у вас много разных задач, а это значит, что вам придется делать меньше изменений схемы с течением времени. Недостаток заключается в том, что вы не пользуетесь гарантиями целостности данных ограничений внешнего ключа и полностью полагаетесь на приложение для добавления хороших данных.

Как и все проектные решения, это предполагает компромисс. В этом случае это компромисс между гарантиями целостности данных и простотой и стабильностью схемы.