多くの場合、「なし」を入れることはそれほど悪くないように思えるかもしれません。ただし、この特定のルックアップ テーブル (数千行) の値を、ルックアップ テーブルからのデータに直接関連するいくつかの null 非許容フィールドを含む別のテーブルで使用したいと考えています。
実際のシナリオ:
ルックアップ テーブルはジェネリック医薬品名のリストであり、アプリケーションとは別の他のデータベースに結合するためのコードが含まれています。
DrugId、OrderId (FK)、頻度、投与量などを保存する処方箋テーブルがあります。現在、これらはすべて null 非許容です。
特定のシナリオでは、注文の処方箋情報が必要になるため、単に記録を持たない (そして他の追跡手段がない) だけでは問題を解決できません。入力された処方箋がない理由と、後日データを確認するときに、正しい理由を再入力できるようにします。
1 つのアイデアは、この質問の基礎を形成する薬のルックアップ テーブルの一部として「なし」を追加することです。いくつかの理由から、このアプローチを採用することを心配しています。
- データを消費するすべてのシナリオで、これを考慮することを忘れないようです (サードパーティ データベースでの内部結合のため、いくつかの小さな例外を除いて)。
- これは、プロジェクトに参加する人にとっては非常に明白ではなく (お尻の痛みは言うまでもありません)、独自にテストする必要があります。「なし」だけでこれを行うのはそれほど悪くないかもしれませんが、ミックスに「拒否」または「不明」を追加したかったのはどうですか? ルックアップ テーブルには、データがアクセスされるたびに考慮しなければならない 3 つの明白でない例外があります。
- 現在必要なフィールドを null 可能にするか、偽のデータを挿入します。
このシナリオに対処するためのその他のアイデアは次のとおりです。
「処方箋あり」、「不承認」、「処方箋なし」などのオプションを含む新しい列をオーダーに追加します。何万もの行が「null」になるため、これは望ましくありませんが、それ以外はそれほど悪くはないようです。
フィールドが必要な場合について、「なし」または「不明」などの「例外的な」ケースのみを記録する新しいテーブルを作成します。これは、説明しなければならない非常に明白な例外的なケースを生み出すため、現時点で私にとって最も魅力的なものです. もちろん、欠点は、非常に少数の列を持つ新しいテーブル (1 ゼロの関係) です。これは、UI を再設定するために使用するデータの最も単純な形式のようです。
SO コミュニティの考えは?
