2

同様の質問があるかもしれませんが、ガイダンスに十分近いものを見つけることができませんでした.

このスペックを考えると、

Site
---------------------------
SiteID      int    identity
Name        varchar(50)

Series
---------------------
SiteID      int
SeriesCode  varchar(6)
...
--SeriesCode will be unique for every unique SiteID

Episode
----------------------
SiteID      int
SeriesCode  varchar(6)
EpisodeCode varchar(10)
...

私の提案する設計/実装は

Site
----------------------------
SiteID      int     identity
Name        varchar(50)


Series
-------------------------------------------
SeriesID    int     identity, surrogate key
SiteID      int         natural key
SeriesCode  varchar(6)  natural key
UNIQUE(SiteID, SeriesCode)
...

Episode
-------------------------------------------
EpisodeID   int     identity, surrogate key
SeriesID    int     foreign key
EpisodeCode varchar(6)  natural key
...

これで何か問題がありますか？ここで SeriesID サロゲートを外部 * キーとして使用しても問題ありませんか? 発生する可能性のある明らかな問題を見逃しているかどうかはわかりません。それとも、複合自然キー (SiteID+SeriesCode / SiteID+EpisodeCode) を使用した方がよいでしょうか? 本質的に、それはエピソード テーブルをシリーズ テーブルから分離することになり、私には合いません。

追加する価値があるのは、これらのテーブルに入力される生の入力データでは、SeriesCode が「ABCD-1」のように見え、EpisodeCode が「ABCD-1NMO9」のように見えることです。

*: 「仮想」外部キー。上層部によって事前に決定されているため、実際の外部キーは使用しないでください。

4

3 に答える 3

4

はい、それはすべてうまく見えます。私が指摘する唯一の（マイナーな）ポイントは、Episode.EpisodeCodeは、Episodeの行を識別して見つけるのに十分な単一属性の自然キーであるため、Episodeからぶら下がっている別の4番目の子テーブルがない限り、EpisodeIdはおそらく必要ないということです。もちろん、そのままにしておいても問題はありませんが、原則として、子テーブルのFKのターゲットとして機能する代理キーを追加し、すべてのテーブルにナラルキーを追加して、冗長なデータ行を識別および制御しようとします...したがって、テーブルにそれを参照するFKを持つ他のテーブルがない場合（そして決してそうしない）、私は時々そのテーブルに代理キーを含めないことがあります。

于 2009-10-27T14:18:20.583 に答える
1

「仮想」外部キーとは何ですか? 上層部は外部キー制約を使用しないことに決めましたか? その場合、外部キーをまったく使用していません。あなたはふりをしているだけです。

また、エピソードはエンティティにとって最良の選択ですか? それは本当にショーやポッドキャストなどを意味するものではなく、たまたま常にシリーズの一部になっているだけですか? もしそうなら、それは将来変わりますか？エピソードは最終的に、シリーズ外のショーを包含するように悪用されるのでしょうか? その場合、シリーズを介してエピソードをサイトに結び付けると、あなたを悩ませる可能性があります.

これらすべてを踏まえて、あなたがうなり声を上げて変更できないと仮定すると、もし私があなただったら、可能な限り自然キーを使用する方が安全だと思います。外部キー制約がない場合、不正なデータの認識が容易になります。また、後で SeriesCode='EMPTY' トリックに頼らなければならない場合でも、自然キーを使用すると簡単になります。

于 2009-10-27T16:09:30.453 に答える
0

私のおすすめ：

次の 3 つの状況を除いて、可能な限り自然/ビジネスを主キーとして使用します。

  1. 自然/ビジネスキーは、挿入の時点では不明です
  2. 自然/ビジネス キーが適切でない(一意ではない、頻繁に変更される可能性がある)
  3. 自然/ビジネス キーは3 つ以上の列の複合であり、テーブルには子テーブルがあります

状況 1 と 2 では、代理キーが必要です。

状況 3 では、代理キーを強くお勧めします。

于 2012-08-24T20:13:11.953 に答える