私は別の暴徒によって開発されたアプリケーションに取り組んでおり、データベース内のすべてのブール列にビットの代わりにcharフィールドを使用することに混乱しています。trueの場合は「Y」、falseの場合は「N」を使用します（これらは大文字である必要があります）。タイプ名自体は、yblnのようなあいまいな名前でエイリアスされます。
これは多くの理由で作業するのが非常に面倒ですが、その中でも特に、見た目がまったく見た目が悪いということはありません。
しかし、おそらくそれは愚かな私です-なぜ誰かがこれをするのでしょうか？それはデータベースの互換性の問題ですか、それとも私が気付いていないデザインパターンですか？
誰かが私を啓発できますか？
私はこの慣習を古いデータベーススキーマで頻繁に見ました。私が見た利点の1つは、CHAR（1）フィールドを使用すると、「はい」、「いいえ」、「たぶん」など、Y/N以上のオプションがサポートされることです。
他のポスターは、Oracleが使用された可能性があると述べています。私が参照したスキーマは、実際にはOracleとSQLServerにデプロイされていました。データ型の使用を、両方のプラットフォームで使用可能な共通のサブセットに制限しました。
OracleとSQLServerの間のいくつかの場所で分岐しましたが、ほとんどの場合、データベース間で共通のスキーマを使用して、両方のDBをサポートするために必要な開発作業を最小限に抑えました。
ブラウンフィールドへようこそ。昔ながらの人がデザインしたアプリを継承しました。これはデザインパターンではなく（少なくとも、何か良いことがあるデザインパターンではありません）、限られたデータ型のデータベースに歯を食いしばったコーダーの痕跡です。DBと多くのコードをリファクタリングすることを除いて、歯を食いしばって、それを通り抜けてください（そしてあなたのケースを見てください）！
他のプラットフォーム（Oracleなど）にはビットSQL型がありません。その場合、NUMBER（1）と単一文字フィールドのどちらかを選択します。たぶん、彼らは別のプラットフォームで始めたか、クロスプラットフォームの互換性を望んでいました。
Y/N char(1) フィールドをビット列の代わりにするのも好きではありませんが、テーブルのビット フィールドには大きな欠点が 1 つあります。ビット列のインデックスを作成できないことです。または、複合インデックスに含めます (少なくとも SQL Server 2000 には含めません)。
もちろん、そのようなインデックスが必要になるかどうかについて話し合うこともできます。SQL Server フォーラムでこの要求を参照してください。
理由は次のとおりです（ところで、それらは正当な理由ではありません）。
1) Y/N は、すぐに "X" (不明)、"L" (可能性が高い) などになる可能性があります。これが意味することは、私が個人的に、要件を正しく収集しないことに慣れているプログラマーと一緒に仕事をしてきたということです。彼らは、展開する必要があるかもしれないという迷信を伴う一種の「フラグ」としてY / Nから始めました（ステータスIDとしてintを使用する必要があります）。
2) 「パフォーマンス」 - ただし、前述のように、「選択的」でない SQL インデックスは除外されます... 可能な値が 2 つしかないフィールドは、そのインデックスを使用しません。
3) 怠惰。-開発者は、人間が読めるように「Y」または「N」の文字を使用して、視覚的なディスプレイに直接出力したい場合があり、それを自分で変換したくない場合があります:)
私が以前に聞いたり見たりした 3 つの悪い理由はすべてあります。
「BIT」列にインデックスを付けられないことによる不利益は想像できません。クエリの実行に役立つ十分な異なる値を持つ可能性は低いからです。
また、ほとんどの場合、BIT と CHAR(1) のストレージの違いはごくわずかだと思います (その CHAR は NCHAR ですか? 16 ビット、24 ビット、または 32 ビットの Unicode 文字を格納しますか? 本当に気にしますか?)
Microsoft SQl 6.5 で開発を開始した可能性があります。
当時、データが配置された既存のテーブルにビット フィールドを追加することは、後部の王様の苦痛でした。ビット フィールドを null にすることはできないため、既存のテーブルにビット フィールドを追加する唯一の方法は、ターゲット テーブルの既存のすべてのフィールドとビット フィールドを含む一時テーブルを作成し、データをコピーしてビット フィールドに入力することでした。デフォルト値で。次に、元のテーブルを削除し、一時テーブルの名前を元の名前に変更する必要がありました。いくつかの外部キー関係を投入すると、長いスクリプトを作成することになります。
そうは言っても、プロセスを支援するサードパーティのツールは常にありました。以前の開発者がビット フィールドの代わりに char フィールドを使用することを選択した場合、その理由は簡単に言えばおそらく怠惰でした。
これは、メインフレーム ファイルや COBOL などでは非常に一般的です。
テーブルにそのような列が1つしかない場合、実際にはそれほどひどいことではありません（実際のビット浪費はありません）。結局のところ、SQL Server では自然なことを言うことはできません。はるかに自然なことではなく、andWHERE BooleanColumnを言わなければなりません。複数のビット列がある場合、SQL Server はそれらをパックします。Y/N の大文字と小文字は、大文字と小文字を区別する照合が使用されている場合にのみ問題になります。無効なデータを停止するには、常に制約のオプションがあります。WHERE BitColumn = 1IF @BitFlag = 1IF @BooleanFlag
そうは言っても、私の個人的な好みはビットでありNULL、慎重に検討した後にのみ s を許可します。
どうやら、ビット列は MySQL ではお勧めできません。
それらはおそらくOracleの使用に慣れていて、SQLServerで使用可能なデータ型を適切に読み取っていませんでした。私自身もまさにそのような状況にあります（そしてY / Nフィールドが私を狂わせています）。
このような癖は、データベースよりもアプリケーションに関連している場合があります。たとえば、PHP と MySQL の間でブール値を処理することは、ちょっと行き当たりばったりで、直感的でないコードになります。CHAR(1) フィールドと 'Y' および 'N' を使用すると、より保守しやすいコードになります。
もっとひどい目にあった...
'true' と 'false' を使用する機会があった 1 つの O/R マッパーは、Java ブール値にきれいにキャストできるためです。
また、データ ウェアハウスなどのレポート データベースでは、DB はユーザー インターフェイスです (メタデータ ベースのレポート ツールに関係なく)。レポートを作成する人々を支援するために、この種のことを行いたいと思うかもしれません。また、2 つの値を持つインデックスは、スター スキーマでのインデックス交差操作で引き続き使用されます。
どちらにしても強い感情はありません。ある方法で別の方法で行うことに大きなメリットがあるとは思えません。哲学的には、ビットフィールドの方がストレージに適していることを知っています。私の現実は、単一のレコードに多くの論理フィールドを含むデータベースはほとんどありません。もし私がたくさん持っていたら、私は間違いなくビットフィールドが欲しいでしょう. 数枚しか持っていないなら問題ないと思います。私は現在、Oracle および SQL サーバーの DB を扱っており、Cullinet の IDMS データベース (1980 年) から始めました。ここでは、あらゆる種類のデータをレコードにパックし、ビットとバイトについて心配していました。データのサイズについては今でも心配していますが、数ビットについて心配することはとうの昔にやめました。