Лучшие практики - Должны ли смешиваться метаданные и данные, определяющие функционал?

Question

Рассмотрим случай простого веб-приложения с новостной статьей, в котором столбец таблицы БД «Статус» доступен с помощью набора переключателей:

Статус - [x] Опубликовать [] Черновик [] Архив

... где «Опубликовать» показывает статью публично, а «Черновик» и «Архив» - нет. Функционально «Черновик» и «Архив» делают то же самое, но несут дополнительные значения метаданных. Два функциональных состояния «показать» и «скрыть» вместе с метаданными «публикация», «черновик» и «архив» смешаны в одном столбце «статус».

Это хорошая практика? Хотя это очень простой случай, более крупные случаи могут выявить недостатки при такой практике (или нет ...).

Answer 1

Функциональные состояния относятся к поведению - их не нужно моделировать в вашей базе данных. Если ваша бизнес-логика заботится только о том, чтобы «показывать» статьи со статусом «Опубликован» - нет смысла удваивать сложность ваших данных с помощью столбца «Показать».

В тот момент, когда вы решаете, что вашей бизнес-логике нужно дополнительные данные , чтобы принять решение о том, показывать или скрывать статью (возможно, флаг IsApproved), тогда вы можете сохранить эти данные.

Если посмотреть на это с другой стороны - если бы вы добавили еще один столбец «Показать», то что бы сделала статья со статусом «Черновик» и «Показать» = 1? Согласно вашим бизнес-правилам это недопустимое состояние.

Answer 2

В этом случае я бы сказал, что это соответствующая функциональность.

Мы все видели WTF в СМИ, где кто-то случайно попал на шоу [x] и черновик [x] одновременно.

Так, как сейчас, невозможно случайно показать черновик. Это важно в газетах, так как журналисты печально известны такими вещами, как:

Джон Доу из StackOverflow сказал: «--- Я не могу вспомнить, что сказал этот уродливый f * cker. - Проверьте ленту и заполните позже»

Который, вероятно, не должен быть напечатан.