次のラジオ ボタン セットでアクセスできる "Status" の DB テーブル列を持つ単純なニュース記事 Web アプリケーションのケースを考えてみましょう。
ステータス - [x] 公開 [ ] 下書き [ ] アーカイブ
...「Publish」は記事を公開して表示し、「Draft」と「Archive」は表示しません。機能的には「ドラフト」と「アーカイブ」は同じことを行いますが、追加のメタデータの意味を持ちます。「表示」と「非表示」の 2 つの機能状態と、「発行」、「下書き」、「アーカイブ」のメタ データが、同じ「状態」の列に混在しています。
これは良い習慣ですか？これは非常に単純なケースですが、より大きなケースでは、そのような慣行の欠陥が明らかになる可能性があります (またはそうでない場合もあります)。
機能状態は動作に関するものであり、データベースでモデル化する必要はありません。ビジネス ロジックが「公開済み」ステータスの記事を「表示」することのみを考慮している場合、表示列を使用してデータの複雑さを 2 倍にする理由はありません。
記事を表示するか非表示にするかを決定するためにビジネス ロジックに追加のデータ(おそらく IsApproved フラグ) が必要であると判断した時点で、そのデータを保存できます。
別の角度から見ると、「表示」の列をもう 1 つ追加すると、ステータスが「下書き」で「表示」= 1 の記事はどうなるでしょうか。ビジネス ルールによると、これは無効な状態です。
この場合、これが適切な機能であると言えます。
誰かが誤って show[x] と draft[x] を同時にヒットしたという WTF をメディアで見たことがあります。
今のままでは、下書きをうっかり見せてしまうことはありえません。記者は次のようなことで悪名高いため、これは新聞にとって重要です。
StackOverflow の John Doe 氏は次のように述べています。
これはおそらく印刷すべきではありません。