私のデータベースでは、テーブルの 1 つにビット (ブール) 値の列がいくつかあります。フィールドには常にデータが含まれているとは限らないため、NULL にすることができます。
テーブルを使用して XSD DataSet を作成するプロセスを完了し、AllowDBNull フィールドが True に設定されていることを確認しました。
ただし、構成された GetData メソッドを使用してデータベースからデータテーブルにダウン レコードをプルすると、次のエラーが発生します。
[InvalidCastException: Conversion from type 'DBNull' to type 'Boolean' is not valid.]
列の DefaultValue フィールド以外に何かを指定する必要がありますか? または、設定する他のフィールドがありますか?
私はまだこのプロジェクトの開発段階にあるので、フィールドを char に変更し、Y/N/NULL オプションを使用することをお勧めしますが、その方法に反対することはあまりありません。
私はイインに反対しなければなりません。3 値ロジックは 2 値ロジックと同様に実行可能です。テーブルの人物は生きているか死んでいるか、生きているか死んでいるかわかりません。もしマイクが彼のやり方を持っていたら、あなたはここでビットを使うことができませんでした. ステータスの表への FK が必要です。1= 生存、2= 死亡、3= 不明です。
ビットの全体的な目的はスペースを節約することです。値を T または F、Y または N (または U) に制限する制約を使用して、常に列を CHAR(1) にすることができます。
しかし、イインはマイクの言っていることを誤解していると思います。マイクは、プロセスが完了するまで EndDate 列を null にする必要があると考えているため、Null の使用を推奨していません。彼は、プロセスが特定の状態にあるかどうかを知るための鍵であるように、列の null 値に神秘的なプロパティを吹き込まないように言っているだけです。
実際、データベース内の Null には、非常に便利な副作用があります。Oracle (おそらく他のデータベース) は null のインデックスを作成しません。SO 1 つの値のみが重要な列がある場合 - たとえば、決してパージしない従業員リストと、インデックスが作成された Is_Active_Employee ビット列があるとします。この場合、確立されたビジネスの場合、これまでの従業員数は、現在の従業員数よりも >>> 多いことになります。1% の 1 と 99% の 0 があるとします。
そのインデックスは、必要以上に 99 倍大きくなっています。すべての 1 にインデックスを付けていますが、これはテーブルの 1% であるため問題ありませんが、そのインデックスを使用して検索できない行には 0 もロードされます。すべての非アクティブな従業員が必要な場合は、インデックスが無視され、FTS が実行されます。したがって、データベースの観点からは、1 と NULL の方がはるかに効率的です。
私見では、ビット/ブール フィールドでヌルを許可しないでください。
これについては、Mike Hadlow が良い記事を書いています。
http://mikehadlow.blogspot.com/2006/10/nullability-voodoo.html
Boolean は、定義上、バイステート型です。null 可能にすることで、3 番目の状態を追加します。ある時点であなたを悩ませるために戻ってきます。