最終的にNOT NULLにする必要があるが、まだ値がない可能性があるフィールドのデータベース設計
私はこの問題に何度も遭遇しました。データベースに保存したい大きなオブジェクトがあるとしましょう。おそらくそれはユーザーの出会い系プロフィールであり、100個のフィールドがあります。プロファイルが完成したら、これらの100個のフィールドすべてに値が必要です。
ただし、100のフィールドすべてを一度に入力するようユーザーに強制することは避けたいです。おそらく、セクションごとにプロファイルを作成できますが、100個のフィールドすべてに値が入力されるまで、「完全」とは見なされません。
これらのフィールドをNULLにしないのはいいことです。結局のところ、NULLはそれらにとって有効な値ではありません。しかし、フィールドがNOT NULL、少しずつ行を作成して、毎回いくつかのフィールドを保存することはできません。
過去に使用した「ソリューション」：
- フィールドをヌル可能にするだけです。データの整合性の保証がいくつか失われているため、これはすばらしいことではありません。アプリのバグはデータの不整合につながります。
- 100のフィールドをいくつかのテーブルに分割します。すべてのフィールドを作成
NOT NULL。これはクエリに複雑さを追加し、少し間違っているように見えます-完成したプロファイルは、1つのテーブルに行を含むべきではありませんが、DBスキーマはこれを許可します。
これを処理するいくつかの良い方法は何ですか？
2つのテーブルとビュー
ミラー化されたスキーマを持つ2つのテーブルがあり、列のNULL可能性のみが異なります。すべてのデータが表示されたら、保留中のテーブルから完全なテーブルにデータを移動します。 2つの和集合を表すビューがある（ビューのスキーマは保留中のテーブルのスキーマと一致します）
フィールドをnullに設定可能（またはnullに設定できないが、該当する場合は空/デフォルトのコンテンツを許可）にして、すべてのフィールドが入力されているかどうかを示すフラグである別のフィールドを追加することができます。デフォルトは0です。フィールドへの入力が成功したり、「終了」と見なされる基準を満たしたりしたら、フラグを1に設定します。これにより、完了したエントリのみのクエリを簡単にフィルタリングできます。
大きなプロファイルオブジェクトがJSON/XMLに単純にシリアル化されるキー/値テーブルのような単純なものに不完全な出会い系プロファイルを保存するのはどうですか。キーを使用してプロファイルを1つずつ編集するときに、プロファイルを取得するだけで済みます。すべてのビジネス検証に合格したら、その時点で、永続化された正規化されたデータベーステーブルに挿入して、プロファイルを削除します。キー/値の「不完全な」テーブル。
これにより、不完全なプロファイルと完全なプロファイルを明確に分離できます。さらに、フィールドが変更された場合でも、単一の列にデータをシリアル化するだけなので、不完全なキー/値テーブルを維持する必要はありません。本当に必要な場合は、そのJSONに統計情報を問い合わせることができます。SQLバージョンほどパフォーマンスが良くないかもしれませんが、それが問題になるとは思いません。
ヌル可能にするだけです
できる場合...できない場合は、この問題を回避するための手品を探し始めてください。最も単純なものはおそらくデフォルト値であり、null値とほぼ同じように動作します。データを取得し、（null | default）を確認して、それに応じて反応します。
デフォルト値を使用できない場合は、ここで提案されている 複雑な選択肢 のいずれかを試してください。とはいえ、問題を解決するために追加された複雑さは、最初からそれらをnullにするだけの力を納得させるだけの問題です。
何かが技術的に可能であるからではなく、それが良い考えであることが必要です。