Tinyint vs Bit？

ここで宗教戦争に触れたくはありませんが、データベースでブール値を表現する方法については2つの考え方があるようです。bit適切なデータ型であると言う人もいれば、tinyintより良いと主張する人もいます。

私が知っている唯一の違いはこれらです：

• bit：ストレージサイズは1ビット、可能な値は0または1です
• tinyint：ストレージサイズは1バイト、可能な値は0〜255です

ブール値を表す必要がある場合、どのデータ型が適していますか？あるtinyint価値が余分なオーバーヘッド「念のために」あなたは値> 1に必要ですか？

テーブルにビット列を追加すると、1ビットだけでなく、各レコードの1バイト全体を占有します。2番目のビット列を追加すると、同じバイトに格納されます。9番目のビット列には2バイト目のストレージが必要です。1ビット列のテーブルには、ストレージのメリットはありません。

Tinyintとbitはどちらも機能させることができます。私は両方をうまく使用しており、強い好みはありません。

ビット...あなたが「true / false /ファイルが見つかりません」クランでない限り

参照を取得しなかった場合...

また、Linq2SQLの場合、ビットはtrue / falseで機能するため、プログラミングが容易になります。両方に利点があります。

また、考慮すべきプログラミングのメンテナンスもあります。あなた（またはジュニアインターンプログラマー）が2、3、25、41、167、200などを使用するとどうなりますか？それはどこに文書化されていますか？ビットは自己文書化されており、かなり普遍的です。

必要に応じてビットを使用します。意味的に正しいタイプ（セマンティクスカウント！）であることに加えて、単一の行（とにかくSQL Server上）の複数のビットフィールド（最大8）を1バイトのストレージに統合できます。8番目以降は、次の8に追加のバイトが必要になります。

参照：

• SQL 2000
• SQL 2005
• SQL 2008

MySqlユーザーの場合-MySQLでBIT列を使用すべきでない理由

以前のStackOverflowの投稿：MySQLのBITとTINYINTの違いは何ですか？

新しい「BOOL」列を追加するとき、MySQLは実際にはTINYINTを使用します。

私はBOOL（別名TINYINT）に固執し、人生を歩み続けます。

ブール値は、定義上、2つの値のみを許可します。なぜこれに1ビット以上のものが必要なのですか？3つ（またはそれ以上）の状態ロジックが必要な場合は、より大きなデータ型を使用しますが、標準のブール論理のビットフィールドを使用します（実際に使用します）。

ビットを使用するのは、チェック制約を使用する手間が省け、ORMがビットをnull許容ブール値（C＃）に自動的に変換するためです。これは、コーディングすると非常に高く評価されます。

Falseのゼロスペース

どちらを選択しても、NULL代わりに設定でき、余分なスペース0は必要ありません（データベースにはほとんどの場合NULL、すべての行のすべてのフィールドにフラグがあり、そこに座っているだけです。詳細はこちら）。また、デフォルト/最も可能性の高い値がfalseであることを確認すると、さらに多くのスペースを節約できます。

真のスペース

表す値にはtrue、フィールドタイプで定義されたスペースが必要です。を使用BITすると、テーブルにそのような列が複数ある場合にのみスペースが節約されます。これは、8フィールドTINYINTごとに1バイトを使用するためです（フィールドごとに1バイトを使用する場合とは異なります）。

TINYINT余分な列の束を管理することを心配せずに8値ビットマスクをカスタマイズできるという利点があり、検索は理論的に高速です（単一の整数フィールドと複数のビットフィールド）。ただし、順序が遅い、クロスインデックス機能が優れている、フィールド名がないなどの欠点があります。私にとって、これが最大の損失です。データベースでは、どのビットがどのビットマスクで何を実行したかを記録するための外部ドキュメントが必要になります。

いずれの場合も、TEXTフィールドを使用してブール値またはそれらのセットを格納する誘惑を避けてください。テキストの検索はサーバーにとってはるかに多くの作業であり、「オン、オフ、オフ」などの任意の命名スキームは相互運用性を損なう可能性があります。

ビット（SQL Server 2k5）でグループ化を試したところ、問題なく動作しました。アプリケーションに正しいデータ型を使用するのが好きです。それが真/偽のフィールドである場合、ビットは私が使用するものです...

これらの理論的な議論はすべて素晴らしいですが、実際には、少なくともMySQLを使用していて、実際にはSQLServerでも使用している場合は、ブール値の非バイナリデータを使用するのが最善です。これは、作業が簡単であるという単純な理由からです。 'データの出力、クエリなど。MySQLとSQLServerの間で相互運用性を実現しようとしている場合（つまり、2つの間でデータを同期する場合）は、BITデータ型の処理が2つで異なるため、特に重要です。したがって、実際には、数値データ型を使用する場合は、煩わしさが大幅に軽減されます。MySQLには、TINYINT（1）として格納されるBOOLまたはBOOLEANを使用することをお勧めします。MySQLWorkbenchとMySQLAdministratorがBITデータ型を表示する方法でさえ、良くありません（これはバイナリデータの小さな記号です）。

上記で見たとは思いませんが、BIT列（MIN、MAX、特にSUMなど）を集約できないという問題があります。2008を使用してテストしたところ、問題はまだ残っています。これが私が最近tinyintを使用する最大の理由です-もう1つは、tinyintのスケーリング方法が好きです-「2値」ビットフラグが突然より多くの可能な値を必要とするとき、それは常に苦痛です。

すべてのテーブルをint「vector」フィールドで作成します。次に、そのフィールドを、任意の目的に割り当てることができる32ビットのコレクションとして使用します。（状態のセットにビットのグループを使用する可能性があります）。忘れた場合にフラグフィールドを追加し続ける必要がなくなります。

@Kevin：group byビットフィールドで使用できると思います（SQL Server 2005）：

declare @t table (
    descr varchar(10),
    myBit1 bit, 
    myBit2 bit
)
insert into @t values ('test1', 0, 1)
insert into @t values ('test2', 1, 0)
insert into @t values ('test3', 1, 1)
insert into @t values ('test4', 0, 0)

select myBit1, count(myBit1) from @t group by myBit1
select myBit2, count(myBit1) from @t group by myBit2

結果：

myBit1 
------ -----------
0      2
1      2

myBit2 
------ -----------
0      2
1      2

TinyIntが私の好みです。次に、フィールドに対して集計カウントを行う場合、それをキャストする必要はありません。また、一部のフロントエンド言語は他の言語とは少し異なって解釈し、TinyIntを使用すると、検証チェックがすべてのフロントエンド言語に対してユニバーサルになります。

MySQLを使用している場合は、BITデータ型を使用することはお勧めしません-http ：//www.xaprb.com/blog/2006/04/11/bit-values-in-mysql/

「T」または「F」でchar（1）を使用するのが好きです。はい、他の値で悪用される可能性がありますが、少なくとも、ビット値またはバイナリ値の操作が難しいレポートやその他の場所で簡単に表示できます。