Составной ключ на самоссылающейся таблице - PullRequest
Новая
       33

Составной ключ на самоссылающейся таблице

1 голос
/ 26 августа 2009

У нас есть составной первичный ключ для таблицы сайта, определенной ниже. Функционально это происходит именно так, как мы хотели бы. Каждый сайт должен иметь родительский сайт того же района. Определение таблицы таким способом позволяет специально для этого. 

    CREATE TABLE [dbo].[site](
        [site_number] [nvarchar](50) NOT NULL,
        [district_id] [bigint] NOT NULL,
        [partner_site_number] [nvarchar](50) NULL,
     CONSTRAINT [PK_site] PRIMARY KEY CLUSTERED 
    (
        [site_number] ASC,
        [district_id] ASC
    )

    ALTER TABLE [dbo].[site]  WITH CHECK ADD  CONSTRAINT [FK_site_site] FOREIGN KEY([partner_site_number], [district_id])

Мой конкретный вопрос касается самоссылающегося FK, определенного на составном ПК. Я слышал несколько мнений об этом конкретном дизайне, и они, как правило, противоречивы. Некоторым это нравится особенно потому, что он функционирует как следует в общем понимании составных ключей. Другие настаивают на том, что это теоретически неверно и что должно быть также поле [partner_district_id], которое включено в FK вместо [district_id]. Этот дизайн потребует проверки для обеспечения того, что [district_id] = [partner_district_id], что может быть сделано либо с проверочным ограничением, либо с логикой уровня приложения.

Буду признателен за дальнейшие мнения относительно этих решений или любых других.

Ответы [ 2 ]

2 голосов
/ 26 августа 2009

Я бы предложил SiteId сам по себе в качестве первичного ключа. DistrictId, вероятно, должен быть внешним ключом?

РЕДАКТИРОВАТЬ - в этом случае я бы предложил добавить дополнительный PartnerDistrictId к внешнему ключу; Вы никогда не знаете, вы можете позже хотеть связать один сайт с другим в другом районе. Но лично я был бы за суррогатный ключ здесь. И в большинстве случаев;)

0 голосов
/ 26 августа 2009

именование комментария ... Является ли Site_Id сам по себе не уникальным? Потому что имя Site_id подразумевает, что оно есть. Если он уникален только в сочетании с District_Id, то, возможно, его неправильно назвали ... это может быть понятнее, если это site_Sequence, District_site_No или что-то еще более понятное.

Если я понимаю вашу модель домена, то все сайты в округе «наследуются» от одного корневого родительского сайта, и между сайтами в разных округах не может быть перекрытия ... если так, то одна и та же функциональность может быть достигнута делая DistrictID обнуляемым, и заполняйте его только для корневых сайтов. Тогда Site_Id может быть одним полем PK, а ParentSiteId может быть одним полем FK. Все «дочерние» сайты будут «принадлежать» району, указанному в записи корневого родительского сайта.

...