SQL Server - външен ключ, препращащ към първичен ключ A ИЛИ B

Да кажем, че имам таблица, наречена Matchup, която съдържа два спортни отбора. Също така имам таблица, наречена Pick, която има колона, която трябва да съответства или на Team_A ИЛИ Team_B. Така че това е външен ключ на една ИЛИ другите колони в Matchup. Възможно ли е това?

Мач
Team_A
Team_B

Избор
Pick_Team - FK Matchup (Трябва да съвпада с Team_A или Team_B от Matchup).


person OperationNewDay    schedule 13.08.2013    source източник
comment
Добавете своя коментар (отговор на astander) към тялото на въпроса. Сега е ясно, че трябва да имате трета маса с всички отбори, нали? И Table Pick след това може да има FK, който е насочен към PK на тази маса.   -  person OzrenTkalcecKrznaric    schedule 13.08.2013


Отговори (2)


Бих разделил вашата Matchup таблица на две: Matchup правилно и MatchupDetails.

Таблицата Matchup ще има колона MatchupID като първичен ключ.

MatchupDetails ще се състои от поне две колони: MatchupID за препратка към Matchup таблицата и TeamID за препратка към Team таблицата (вие наистина имате такава, нали?). Двете колони ще образуват съставния първичен ключ на таблицата.

И накрая ще има тази Pick таблица. Тъй като имате множество потребители (според един от вашите коментари), ще трябва да има препратка UserID. Още две колони, MatchupID и TeamID ще служат като съставен външен ключ, препращащ към съответния набор от колони в MatchupDetails. И за да се гарантира, че един потребител може да избере не повече от един отбор от съвпадение, съставният първичен ключ от (UserID, MatchupID) трябва да е подходящ.

За да обобщим, ето пълно описание на съответната част от схемата:

  • Matchup:

    MatchupID
    PRIMARY KEY (MatchupID)
    
  • MatchupDetails:

    MatchupID
    TeamID
    FOREIGN KEY (MatchupID)
    FOREIGN KEY (TeamID)
    PRIMARY KEY (MatchupID, TeamID)
    
  • Pick:

    UserID
    MatchupID
    TeamID
    FOREIGN KEY (UserID)
    FOREIGN KEY (MatchupID, TeamID)
    PRIMARY KEY (UserID, MatchupID)
    
person Andriy M    schedule 13.08.2013
comment
Да, имам таблици Team и User. Вярвам, че това или някаква близка вариация е това, което търся. Благодаря! (Бих гласувал за отговора, но все още нямам достатъчно репутация...) - person OperationNewDay; 13.08.2013
comment
Добре, изпробвах това и работи страхотно. Първоначално бях объркан, защото таблицата за съвпадение в горния пример има само идентификатор. Добавих „Matchup_Date“ и „Matchup_Venue“ заедно с няколко други колони и след това стана напълно логично. - person OperationNewDay; 18.08.2013

Не мисля, че това е правилният подход.

По-скоро бих препоръчал да добавите допълнително поле към таблицата Matchup (да кажем Pick) и да добавите ПРОВЕРЕТЕ ОГРАНИЧЕНИЕТО, за да се уверите, че е Team_A или Team_B.

Ограниченията CHECK налагат целостта на домейна чрез ограничаване на стойностите, които се приемат от една или повече колони. Можете да създадете ограничение CHECK с всеки логически (булев) израз, който връща TRUE или FALSE въз основа на логическите оператори.

От Ограничения на FOREIGN KEY

В препратка към външен ключ се създава връзка между две таблици, когато колоната или колоните, които съдържат стойността на първичния ключ за една таблица, са препратени от колоната или колоните в друга таблица. Тази колона става външен ключ във втората таблица.

И изглежда не е това, което търсите.

person Adriaan Stander    schedule 13.08.2013
comment
Това може да е това, което търся. За да разширя примера, имам множество потребители, които избират кой да спечели тази игра, поради което я имам в отделна таблица. Поставянето на Picks в същата маса като Matchup би победило това. Може ли ограничение за проверка да препраща към колони от различна таблица? - person OperationNewDay; 13.08.2013
comment
От stackoverflow.com /questions/3880698/ изглежда, че можете да създадете UDF, който ще постигне това, от което се нуждаете. - person Adriaan Stander; 13.08.2013