- フィールドの一意性制約に対してデータベースインデックスが作成される場合、または複数フィールドの一意性制約に対して複数のインデックスが作成される場合、他のデータベースインデックスとほぼ同じように、オブジェクトをクエリするときに効率を上げるために同じインデックスを使用できますか?使用されている?私の推測では、一意性制約用に作成されたインデックスは効率向上のために作成されたものと同じであり、一意性制約自体は追加のものですが、データベースに精通していません。
- 長いトランザクションや高い同時実行性などを通じて、複数のフィールドの制約(たとえば、field_aとfield_bが一緒に一意である)を含む一意の制約を破ることは可能ですか?または、一意の制約によって100%の保護が提供されますか。
3 に答える
はい。一意の制約は(SQL Serverの)インデックスであり、クエリプランで使用できます(使用できます)。
不可能だよ。トランザクション時間や同時実行性の問題に関係なく、制約に違反するテーブルにデータを格納することはできません(少なくともSQL Serverでは)。ところで、トランザクションが長すぎて心配な場合は、このトランザクションのコンテキストで何をしているかを再考する必要があります。長いトランザクション操作でデータベースの制約に違反することはありませんが、他の問題が発生します。
質問1について:
はい-これらは、定義する他のインデックスと同じようにインデックスであり、たとえばパフォーマンス向上のためにクエリプランで使用されます...「一意の制約」を定義せずに一意のインデックスを定義できます。
質問2について:
はい-DBエンジンがACIDに準拠し、信頼できる(つまり、この点でバグがない)限り、また制約を一時的に無効にしない限り、100%保護されます。
あなたの質問の問題は、それが非常に一般的であり、特定の実装に合わせて調整されていないということです。したがって、どのような答えも非常に一般的です。
この心の中で:
データベースがインデックスを介したアクセスが物事をスピードアップするかもしれないと考えるときはいつでも、それはそうするでしょう-ここでは一意性は関係ありません。1つのテーブルに多数のインデックスが存在する場合、適切なデータベースは「最良の」データベースを使用しようとします。実際の「最良」の意味についてはさまざまな見方があります。ただし、多くのデータベースは1つのインデックス のみを使用して行を取得します。したがって、経験則として、DBは通常、ルックアップの結果が可能な限り少ない行になる場合にindizeを使用しようとします。ユニークなインデックスはこれに非常に優れています。:-)
実際、これは1つのポイントではなく、2つの異なるポイントです。
適切なDBは、実行時間の長いトランザクションや同時実行性が高い場合でも、インデックスを破損することはありません。少なくともわざとではありません。もしそうなら、それはDBソフトウェアのバグであり、非常に迅速に修正する必要があります。そうしないと、DBベンダーは非常に劇的な方法で評判を失う可能性があります。もう1つの可能性は、それがまともなDBではなく、単なる永続的なハッシュマップなどであるということです。データが本当に重要である場合、高い同時実行性と長時間実行されるトランザクションは言い訳にはなりません。
複数値の一意のインデックスは獣です。DBの実装はまったく異なり、1つ以上のキー列にが含まれている場合に「一意」と見なされます
NULL
。たとえば、この点に関するPostgreSQLのドキュメントを見ることができます:http ://www.postgresql.org/docs/9.1/interactive/indexes-unique.html
これがいくつかのことを明らかにすることを願っています。