Создать основную таблицу для столбца статуса

Question

У меня есть таблица, представляющая запрос, отправленный через веб-интерфейс

coupon_fetching_request
---------------------------------------------------------------
request_id    | request_time  | requested_by  | request_status

Выше я пытался создать таблицу для решения проблемы.
Здесь request_status - это integer. Некоторые значения могут быть следующими:

1 : request successful
2 : request failed due to incorrect input data
3 : request failed in otp verification
4 : request failed due to internal server error

Эта таблица очень проста, и ее статус используется, чтобы позволить веб-интерфейсу узнать, что случилось с отправленным запросом. У меня была дискуссия с моей командой, и другие разработчики предлагали, чтобы у нас была таблица представления статуса . На стороне базы данных нам не нужен этот статус. Но команда говорила, что в будущем нам может понадобиться показать простой вывод из базы данных, чтобы показать состояние всех запросов. Согласно принципу YAGNI , я не думаю, что это хорошая идея.

В настоящее время я закодировал преобразование возвращенного значения request_status в описательное значение во внешнем интерфейсе. Я пытался убедить команду, что могу создать перечисление на бизнес-уровне для представления значения статуса ИЛИ я мог бы добавить документацию на веб-интерфейсе и в Java, но не смог убедить их.

Предлагаемая таблица выглядит следующим образом

coupon_fetching_request_status
---------------------------------------------------
status_id   | status_code   | status_description           

У меня вопрос: нужно ли создавать таблицы для такого простого состояния в подобных случаях.

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

Answer 1

Вы должны создать справочную таблицу в базе данных. В настоящее время у вас есть бизнес-логика на стороне приложения, интерпретирующая данные, хранящиеся в базе данных. Это кажется опасным.

Что означает «опасный»? Это означает, что для специальных запросов к базе данных может потребоваться повторная реализация логики. Это может привести к ошибке.

Это означает, что если вы добавляете интерфейс для отчетов, то отчеты должны повторно реализовывать логику. Это может привести к ошибкам и кошмару обслуживания.

Это означает, что если у вас есть другой разработчик или другой модуль, то может потребоваться повторная реализация логики. Красный флаг.

Самое простое решение - иметь справочную таблицу для определения официального значения кодов. Приложение должно использовать эту таблицу (через join) для возврата строк. Приложение не должно определять значение кодов, хранящихся в базе данных. YAGNI не применяется, потому что приложению так нужна эта информация, что оно реализует саму логику.

Answer 2

Это действительно зависит от вашего варианта использования.

Для начала: в вашей главной таблице вы уже храните request_status как целое число, что хорошо (если вы сохраняете все описание, например 'request successful', это не будет оптимизировано)).

Основной вопрос: нужно ли вам в конечном итоге отображать эти данные в удобочитаемом формате?

Если нет, то, вероятно, бесполезно создавать таблицу представления.

Если да, то было бы неплохо иметь таблицу представления вместо добавления некоторого кода на уровне представления ввыполнить транскодификацию;пусть данные хранятся в базе данных, а внешний интерфейс заботится только о представлении.

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