1

サッカーの試合を表すテーブルがあります。

  • 日にち
  • 相手

{Date,Opponent} が主キーだと思います。このテーブルでは、日付ごとに複数の対戦相手が存在することはあり得ないからです。問題は、他のテーブルに外部キー制約を作成するときに、他のテーブルに Date 列と Opponent 列の両方を含める必要があることです。

サッカー試合の統計表:

  • 日にち
  • 相手
  • イベント（得点、イエローカードなど）

理想的には、次のものが必要です。

サッカーの試合表:

  • ID
  • 日にち
  • 相手

サッカーの試合統計表:

  • サッカーマッチID
  • イベント（得点、イエローカードなど）

ここで、SoccerMatch.ID は一意の ID (主キーではありません) であり、{Date,Opponent} は依然として主キーです。

問題は、{Date,Component} が主キーであるのに対し、SQL Server では ID を一意の ID として定義できないように見えることです。ID のプロパティに移動すると、一意の識別を通知する部分が「いいえ」でグレー表示されます。

（私は、より良い設計であるため、上記を達成しようとするべきであることに誰もが同意すると思いますか？）

4

1 に答える 1

1

ほとんどの人はこれを行うためにグラフィカル デザイナーを使用しないと思います。これを妨げているのはグラフィカル デザイナーであって、SQL Server ではありません。クエリ ウィンドウで DDL を実行してみてください。

ALTER TABLE dbo.YourTable ADD ID INT IDENTITY(1,1);
GO
CREATE UNIQUE INDEX yt_id ON dbo.YourTable(ID);
GO

これで、他のテーブルでこの列を問題なく参照できます。

CREATE TABLE dbo.SomeOtherTable
(
  MatchID INT FOREIGN KEY REFERENCES dbo.YourTable(ID)
);

IDとはいえ、列名はまったく役に立たないことがわかりました。の場合、スキーマに表示されるすべての場所でそれMatchIDを呼び出してみませんか? MatchIDはい、PK テーブルでは冗長ですが、モデル全体の一貫性がより重要です。

さらに言えば、なぜあなたのテーブルは と呼ばれているのSoccerMatchですか? 他の種類のマッチはありますか？Matches一意の ID = であると思いますMatchID。そうすれば、後でさまざまな種類の試合が発生した場合に、スポーツごとに新しいテーブルを作成する必要がtypeなくなります。何らかの列を追加するだけです。サッカーしかないのなら、それSoccerMatchはちょっと冗長ですよね？

また、キーと一意のインデックスを逆にすることをお勧めします。複数列のキーを外部参照に使用する予定がない場合は、少なくとも私にとっては、PKを他のテーブルで参照するものにする方が直感的です。だから私は言うだろう：

CREATE TABLE dbo.Matches
(
  MatchID INT IDENTITY(1,1),
  EventDate DATE, -- Date is also a terrible name and it's reserved
  Opponent <? data type ?> / FK reference?
);

ALTER TABLE dbo.Matches ADD CONSTRAINT PK_Matches
  PRIMARY KEY (MatchID);

ALTER TABLE dbo.Matches ADD CONSTRAINT UQ_Date_Opponent
  UNIQUE (EventDate, Opponent);
于 2013-01-27T17:20:24.363 に答える