データベースにUNIQUE制約が必要なのはなぜですか?
例を挙げていただけますか?
主キーはデフォルトでUNIQUEです...他のテーブルでは外部キーと呼ばれているので理解できます...rdbmsプラットフォームに接続するには関係が必要です...
しかし、なぜ他の列をUNIQUEと呼ぶのでしょうか、そうすることの利点は何ですか?)
データベースにUNIQUE制約が必要なのはなぜですか?
例を挙げていただけますか?
主キーはデフォルトでUNIQUEです...他のテーブルでは外部キーと呼ばれているので理解できます...rdbmsプラットフォームに接続するには関係が必要です...
しかし、なぜ他の列をUNIQUEと呼ぶのでしょうか、そうすることの利点は何ですか?)
データベースが期待に準拠していることを確認するために、可能な限り制約を使用する必要があります。この特定のケースでは、データ品質を確保するために一意の制約が最も役立ちます。
一意の制約は、たとえば、電子メールアドレス列で役立つ場合があります。これは、2つの行が同じ電子メールアドレスを持たないことを要求しますが、PKではなく、通常は変更できます。
一意性が期待され、値がPKなどによってまだ制約されていない場合はいつでも、一意性制約を追加することで、仮定が常に保持されるようにすることができます。
一般に、制約はオプティマイザーでも使用できます。
制約に関するCelkoのシリーズの2番目の記事は、特に固有の制約に関するものです。
何かが主キーである場合、それが変更されることはないと思います。データベース内の他のテーブルへのリンクに使用されるため、静的である必要があります。「主キー」が変更される場合(たとえば、ユーザー名)、それはテーブルの追加フィールドである必要があり、代わりに主キーはある種の増分IDである必要があります。
ただし、同じユーザー名を持つ2人のユーザーを持つことはできません。その場合、一意の制約が保証されます。
ユーザー名は一意ですが、PKではありません。UserIdはPKです。
PKとUQにはいくつかの違いがあります。PKにはNULL値を含めることはできませんが、UQには1つのNULL値を含めることができます(Oracleでは複数のNULL値を使用できます)。テーブルごとに1つのPKしか持てませんが、テーブルごとに複数のUQを持つことができます。デフォルトでは、PKはクラスター化されています(ただし、そうである必要はありません)。
ほとんどの場合、データベースを設計するときは、主キーをIDフィールドとして保持します。アイデンティティフィールドとして作成することは理にかなっていますが、一意性を実現するという問題は解決されない可能性があります。行が一意であることを確認するために、列に一意の制約を設定します(AndreyがUserNaneを指定したため)。これはMSDNが言うことです:
UNIQUE制約を使用して、主キーに関与しない特定の列に重複する値が入力されないようにすることができます。UNIQUE制約とPRIMARYKEY制約はどちらも一意性を強制しますが、主キーではない列または列の組み合わせの一意性を強制する場合は、PRIMARYKEY制約の代わりにUNIQUE制約を使用します。
HTH
データが一意である必要がある場合は、一意の制約が必要です。そうしないと、貧弱なデータが得られます。PKは一意である必要がありますが、他のデータも一意である必要がないという意味ではありません。おそらく、各レコードには一意の日時が必要です。これがPKである可能性は低いですが、一意性を何らかの方法で適用する必要があります。
特に、PKに代理キーを使用する場合(これを強くお勧めします)、データの重複を避けるために、自然キーフィールドが一意の制約の一部であることを確認する必要があります。
ルックアップタイプのデータについても同じです。ユーザーがデータを入力するときに選択できる医師向けの専門分野のリストがあり、必要に応じてこのリストに追加することも許可されているとします。独自の制約により、腫瘍専門医が複数回入力されるのを防ぐことができます。これにより、実際に腫瘍専門医である人数を確認したい場合に簡単になります。
emailIDは一意にすることができます。
uniqueIDとPrimarykeyの違いは、列全体で単一のnullを一意にサポートすることですが、PKはサポートしません。