6

数年前、サードパーティによって開発されたシステムの DB スキーマを見て、ブール値 (tinyint) フィールドの代わりに enum('y','n') を使用していることに気付きました。理由はわかりませんが、とても気に入りました。読みやすくなったことがわかりました（完全に主観的なことです）が、それを採用して以来、使い始めました。「true」と「false」を交換できると思いますが、何と言うか、ただ気に入っただけです。

そうは言っても、このように物事を行うことに何か障害はありますか? ゲームの後半にやってくるプログラマーを少しいらいらさせることを除けば?

4

3 に答える 3

10

はい、それは悪いです。それを使用すると直感的なブール論理が失われ（にSELECT * FROM user WHERE NOT bannedなりSELECT * FROM user WHERE banned = 'n'ます）、アプリケーション側でブール値の代わりに文字列を受け取るため、そこでのブール条件も扱いにくくなります。あなたのスキーマを扱っている他の人々は、旗のような列名を見て、それらにブール論理を使用しようとすることに悩まされます。

于 2012-06-04T13:52:59.837 に答える
1

マニュアルで説明されているように：

に無効な値ENUM(つまり、許可された値のリストに存在しない文字列) を挿入すると、代わりに空の文字列が特別なエラー値として挿入されます。この文字列は、数値 0 を持つという事実によって、「通常の」空の文字列と区別できます。列挙の数値インデックスの詳細については、セクション11.4.4「列挙リテラルのインデックス値」</a> を参照してください。値。

厳密な SQL モードが有効になっている場合、無効なENUM値を挿入しようとするとエラーが発生します。

この点で、は型ENUMとは異なる動作をします。BOOLEANそうでなければ、アプリケーションとの統合が少し直接的でなくなるという@lanzzの答えに同意する傾向があります。

于 2012-06-04T13:58:54.610 に答える
0

考慮すべき要素の 1 つは、元のスキーマを作成した人がそれを MySQL に限定しているかどうかです。MySQL でのみ実行することを意図している場合、MySQL に適応することは理にかなっています。同じスキーマを他の DBMS で使用できるようにする場合は、関連するすべての DBMS で機能する、より一般的なスキーマ設計の方が、設計を行う担当者にとって優れている可能性があります。

そうは言っても、enumはある程度 MySQL 固有ですが、同等のものenumは他の DBMS で簡単に作成できます。

CREATE TABLE ...
(
    ...
    FlagColumn   CHAR(1) NOT NULL CHECK(FlagColumn IN ('y', 'n')),
    ...
);

さまざまな DBMS が BOOLEAN を処理する方法は、SQL 標準にもかかわらず、あなたが望むほど均一ではありません (そして、その理由は、これまでと同様に歴史です。準拠性の低いシステムでは、標準よりも前に BOOLEAN のテーマにバリエーションがありました。 、実装を変更すると、既存の顧客のコードが壊れます)。

enumしたがって、 overの使用を自動的に非難するつもりはありませんが、ブール値フラグbooleanに使用する方が適切です。boolean

于 2012-06-04T14:51:29.980 に答える