私は過去数年間、主に Oracle で作業しており、1 文字の varchar 列がブール値として使用されるのをよく目にします。
また、（スタックオーバーフローの回答ごとに）MySQLの推奨タイプがTINYINTであることもわかります。
今、私は小さな副業を始めました - DerbyDB を使用して、それは BOOLEAN 列をサポートしますが、バージョン 10 程度になるまではサポートしません。
問題は、リレーショナル データベースの設計時に BOOLEAN 列を組み込むのがなぜそれほど難しいのかということです。何かが足りないのでしょうか、それとも別の列タイプを使用できるので、To Do リストに重要ではないとして押し下げられただけですか?
具体的には、Derby の場合、その答えは少し奇妙な歴史にあります。オープン ソース データベースである Derby は、かつて Cloudscape と呼ばれ、独自の製品でした。当時は、BOOLEAN を完全にサポートしていました。
その後、Cloudscape は IBM が買収した Informix によって買収され、IBM エンジニアリングは Derby を DB2 と互換にすることを決定しました。その理由は、2 つのデータベースに互換性があれば、ユーザーが Derby データベースと DB2 データベースの間でアプリケーションを移行しやすくなるためです。しかし、エンジニアリング スタッフは Derby から DB2 と互換性のない機能を削除しませんでした。単に SQL 文法でそれらを無効にし、実装のほとんどを残しました。
その後、IBM は Cloudscape を Apache Software Foundation にオープンソース化し、Derby と名付けました。Derby が DB2 と完全に互換性があるという要件に縛られなくなったオープン ソース コミュニティは、BOOLEAN データ型のサポートを復活させることを決定しました。そのため、Derby は BOOLEAN データ型をサポートするようになりました。
Tom Kyteは、このブログエントリの最後の文をほぼ反映しています。
「それは私たちが持っているタイプではありません-私はこれ以上もそれ以下も言えません。ANSIはそれを持っていません-多くのデータベースはそれを持っていません（私たちは確かに一人ではありません）。 -これの優先順位付けはかなり「低い」と思います（それが私の意見です）。
彼はオラクルの観点から話していますが、それはあらゆるリレーショナルRDBMSに当てはまります。
PostgreSQL はboolean、私が考える限り、サポートしています。
私が見つけた最も古いオンライン ドキュメントは、1998 年 3 月 1 日にリリースされたバージョン 6.3 のものです。彼らはブール型について言及しています：
http://www.postgresql.org/docs/6.3/static/c0805.htm
後のドキュメントでは、従う標準として SQL99 について言及しています。
SQL99 はこの型に言及しているように見えるので、1999 年より前に多くの DB がその型をサポートしていたと思います。
私は設計していないのでわかりませんが、RDBMS は一連のものを記述して格納するためのものであるため、ブール型フィールドはセット内にあるものも示すため不要であると推測されますが、セットのメンバーシップは実際のデータまたはデータベースの構造から派生するため、無関係です。
例として、従業員に与えられた役割のブール列を取り上げます。従業員はマネージャーであるか、マネージャーではないかのいずれかです。これを説明するためにブール列を使用することもできますが、管理者用のテーブルと非管理者用のテーブルを用意するか、(これがより柔軟で、おそらくより管理しやすい方法です) 追加の「外観」を作成する必要があります。役割を (単一のテキスト列として) 与える "up" テーブルと、次に employees テーブルで参照されるキー (外部キー) を作成します。
ほとんどの場合、テーブルにブール型フィールドが表示されますが、これはコードのにおいです。意思 パフォーマンスに影響を与える可能性があります - where 句でブール値を使用すると、テーブル スキャンが呼び出され、テーブルのインデックスがかなり無意味になります (ただし、これに関する詳細な説明についてはコメントを参照してください)。必要な奇妙な条件ステートメントを支援するために、手続き型言語拡張 (T-SQL、PLSQL) で使用するために、ほとんどの RDBMS にブール型のデータ型が追加されているという別の推測を危険にさらします。