Внешние ключи и индексы SQL Server 2005

Question

У меня общий вопрос относительно табличных индексов для внешних ключей при моделировании базы данных. Если у меня есть таблица TABLE_A, созданная как:

CREATE TABLE [dbo].[TABLE_A](
 [ID] [int] IDENTITY(1,1) NOT NULL,
    [RelatedTableBID] [int] NOT NULL,
    CONSTRAINT [PK__TABLE_A] PRIMARY KEY CLUSTERED 
    (
      [ID] ASC
     ) WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF,  
     IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON)   
     ON [PRIMARY]
) ON [PRIMARY]

ALTER TABLE [dbo].[TABLE_A]  WITH CHECK 
ADD  CONSTRAINT [TABLE_A__RelatedTableB]     
FOREIGN KEY([RelatedTableBID])
REFERENCES [dbo].[TABLE_B] ([ID])

и Таблица_B как:

CREATE TABLE [dbo].[TABLE_B](
 [ID] [int] IDENTITY(1,1) NOT NULL,
    CONSTRAINT [PK__TABLE_B] PRIMARY KEY CLUSTERED 
    (
      [ID] ASC
     ) WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF,  
     IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON)   
     ON [PRIMARY]
) ON [PRIMARY]

Будет ли на практике эффективнее, если я создам индекс для ссылочной таблицы (Table A), ссылающейся на столбец (RelatedTableBID)? Как в:

CREATE INDEX TABLE_A_FK_INDEX1 on TABLE_A(RelatedTableBID)

Или я думаю об этом задом наперед? Похоже, что ссылка на столбец сама по себе является кластеризованным индексом, поэтому при соединениях не должно быть проблем - во всяком случае, только удаления из TABLE_B кажутся подверженными низкой производительности.

Спасибо за любую помощь в установлении меня прямо.

-Mustafa

EDIT
Итак, в общем, если я когда-либо последовательно присоединяюсь или использую столбец в предложении where при запросе, следует ли мне добавить в него индекс? Каковы некоторые рекомендации и "практические правила" для создания индексов базы данных? Похоже, что это в общем здравое решение.

Answer 1

Вы правильно поняли. Этот индекс внешнего ключа должен помочь всякий раз, когда вам нужно соединить TABLE_A и TABLE_B.

Answer 2

Нет. То, что вы ищете, это третий стол. Если вы хотите построить отношения «многие ко многим», невозможно обойтись без отвратительно неэффективного дизайна БД без третьей таблицы.

Таким образом: Таблица 'users': uid, first, middle, last Таблица «адреса»: помощь, улица, город, штат, страна и т. Д. Таблица 'users-address': id, uid, aid

Тогда вы можете установить множество ассоциаций в третьей таблице. Обычно это называется нормализацией базы данных.

Итак, ваш запрос ассоциативного запроса будет выглядеть примерно так:

ВЫБРАТЬ * ОТ пользователей, адреса. ПРИСОЕДИНЯЙТЕСЬ к пользователям.

.. даст вам всю информацию о пользователях и адреса для пользователя '1'