私の会社のソフトウェア製品では、多くのデータベース テーブルが「display_order」フィールドを利用しています。ページ上の要素の表示順序を制御する整数です。
私の腸の奥深くで、これは悪い習慣だと感じています。(または、少なくとも、最適とは言えない設計の選択)。しかし、なぜこれが悪い習慣なのか、自分自身を明確にするのに苦労しています。
これまでのところ、私が思いついた唯一の理由は次のとおりです。
ビューをモデルにミックスします。
順序の変更は、多くの異なる行に影響を与える可能性がある高価なデータベース操作です。
多くの場合、要素の順序がわかっている場合、テーブルが十分に小さいため、最初からテーブルが無駄である可能性があります。たとえば、「ステータス」テーブルでは、ステータスは別の「ルックアップ」テーブルではなく、ハードコードされた単純な配列である必要があります。
データベース設計で「display_order」フィールドを回避するための適切な議論はありますか?
場合によっては、これがアイテムの注文に最適なオプションです。
特に - アイテムに自然な順序付けがない場合、または自然な順序付けがプログラムで簡単に実行できるものではない場合 (たとえば、自然言語 - 音素)。
逆もまた真であり、そのようなフィールドに対する議論の「要点」となります。項目に簡単に実装できる自然な順序 (数値、アルファベット ベット) がある場合、そのようなフィールドには場所がありません。
この議論は、アイテムの並べ替えを設定するというユーザーの要件を無視しています。そのような要件が存在する場合は、「display_order」フィールドを使用することをお勧めします。
大変なことだと思いますが、ご存知の方もいらっしゃると思います。私が反対している唯一の議論は、システムのコンポーネントの役割間の論理的な違いを曖昧にするということです。
ただし、多くのプロジェクトでは、データは挿入の順序に基づいて返され（ソースデータのアルファベット/数字の順序に基づいて挿入を実行する主キーとスクリプトが自動インクリメントされるため）、サイト/他のソフトウェアはこれを使用します暗黙の仮定としての順序付け。デフォルトの順序を乱すのは、データを更新したときだけです。「データベースでここに表示順序が必要なようです」と人々は言います。
私が「表示順序」を使用した実装の大部分では、フライアウトでのナビゲーション/サブナビゲーションに関連しています。この場合、クライアントは通常、専門知識を持っていないか、コードやデータベースに触れる必要がないため、ドラッグアンドドロップとともに表示順序を使用することが最も効率的な設計であることが証明されました。クライアントが特に直感的な順序なしでページにアイテムを表示したい場合や、特定のページ要素を簡単に操作できる交換可能な順序で表示することを選択したい場合がよくあります。display_orderはこのタスク専用に設計されているため、それは理にかなっている。
多くの場合、要素の順序がわかっている場合、テーブルが十分に小さいため、最初からテーブルが無駄である可能性があります。たとえば、「ステータス」テーブルでは、ステータスは別の「ルックアップ」テーブルではなく、ハードコードされた単純な配列である必要があります。
データベースの専門家として、私はこれに反対しなければなりません。あなたのステータスが何らかの整合性の制約に関係している可能性は十分にあります。その場合、それらをテーブルに配置すると、行を挿入するだけでメンテナンス (通常は "あと 1 つ" のステータスを追加する) が簡単になります。
そのようなことを CHECK 制約として実装することもできますが、それを変更する (「あと 1 つだけ」ステータスを追加する) とは、テーブルを変更することを意味し、通常は QA とテストを往復することになります。テーブルに行を追加する場合、通常、QA や回帰テストは必要ありません。
ただし、アプリケーション コードで配列をハードコーディングすることによって、整合性制約に関与するステータスを実装することはできません。アプリケーション コードは、すべてのアプリケーションとすべてのユーザーの間で共有される制約 (またはビューの順序付け) を強制する立場にありません。それができるのは dbms だけです。