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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

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