フィールドがIS NOT NULLの場合、ブールフィールドとチェックを追加しますか？

Question

レコードの管理者承認が必要なテーブルを使用して、レコードが公開されるようにします。私は、主なクエリが承認された（またはまだ承認されていない）レコードを検索するようなテーブルを設計するのに最も適切な方法が何であるか疑問に思っています。

照会列は、索引付けされると仮定すると：

1. ブールフィールドを使用する任意の速度の利点がありますか？
2. カラムがNULLかどうかをチェックすることはベストプラクティスに反しますか？たとえば、

：

id | title | text | approved | approved_dttm 
--------------------------------------- 
1 | ... | ... | 0  | null 
2 | ... | ... | 1  | 2017-01-01 00:00:00 ETC 


SELECT * FROM table where approved = 1; 

注対

id | title | text | approved_dttm 
--------------------------------------- 
1 | ... | ... | null 
2 | ... | ... | 2017-01-01 00:00:00 ETC 


SELECT * FROM table where approved_dttm IS NOT NULL; 

：我々は、承認/承認のない以外の複数の状態を必要としません。いいえ "さらにレビューする必要があります。

Answer 1

Qブール値フィールドを使用するとスピードメリットはありますか？

A：NO。

この場合、approvedの列とapproved_dttm IS [NOT] NULLを使用することによる「速度の向上」を得るクエリはほとんどありません。その列に

承認された列の追加バイトは無視ですが（余分なバイトが本当にブロックに「フィット」の行数に影響を与えないこと、それはTINYINTとして定義されていますと仮定した場合）... インデックス無視できません。それは追加のブロック（スペース）を必要とし、インデックスエントリのメンテナンスにオーバーヘッドを追加します。

私たちは、その列の追加が有益であろういくつかの例外的なコーナーケースを除外することはできませんが、一般的には、提供される情報与えられた、いや、その列を追加することへの「速度の利益は」ありません。

（ここでは、冗長データと更新異常について説明します... approved列を3番目の正規形の面に追加し、よく知られているマントラ「すべての属性はキー、キーのみ、そしてキー以外は何もありません」

Q：ベストプラクティスに反して、列がNULLかどうかを確認していますか？

A：NO。

私が知っている "ベストプラクティス"に反していません。 NULLと3値ブール論理は永遠に残っています（1970年にEFCoddが最初に "リレーショナル"、1977年にSystem/RとOracleが登場し、1983年にDB2が登場して以来）...

アプリケーション開発者は、NULL値のニュアンスをどのように処理するのが好きではないかもしれません。そして、NOT NULLとして定義された列を持つことは、やや負担を軽減する可能性があります。しかし、私の本では、 "NULLを扱うことを避ける"はではなく、 "ベストプラクティス"です。

col IS NULL述語を満たすためにインデックスを使用しないデータベース実装のいくつかの欠点があることに注意してください。しかし、これらの欠点は、通常、適切に定義された索引と慎重に書かれた問合せによって克服されます。 NULL値とそれらの癖を理解し、それを扱うのはです。は「ベストプラクティス」です。

Answer 2

1）approvedフィールドを追加すると、approved_dttmから派生できる情報が複製されるだけであるため、情報の観点から追加する点はありません。

2）ビューのインデックスの観点から、あなたはブール（まあ、tinyint型）フィールドにインデックスが日時フィールドをインデックスよりも小さくなっていると主張することができます。しかし、このインデックスの選択性は低く（可能な値は2つしかありません）、実際にデータを選択するときにMySQLがそのインデックスを無視する可能性があります。

全体として、エントリが承認されたかどうかを示すために追加のブールフィールドを追加しません。