Совет по проектированию таблиц SQL Server

Question

Это может быть глупый вопрос.

Некоторые рекомендации по эффективности для SQL Server 2008 R2, хотя эти серверы будут обновлены до 2014 года в течение следующих нескольких месяцев. Я создаю 3 таблицы.

• t1 имеет много колонок различных типов и идентификационный числовой идентификатор, который является первичным ключом. Я ожидаю, что эта таблица войдет в низкие 1000 строк.

• t2 имеет отношение один-много с t1. Первичный ключ будет состоять из идентификатора t2 ID и t1. Цифровой идентификатор t2 будет отправлен приложением frontend и будет уникальным для каждого идентификатора t1. Я ожидаю, что эта таблица вернется к 50000+ строкам. Помимо этих 2 ID, он будет содержать несколько столбцов varchar различной длины.

• t3 имеет отношение один-много с t2. Первичный ключ может быть составным из идентификатора t3, идентификатора t1 и идентификатора t2. Опять же, числовой идентификатор t3 будет отправлен приложением frontend и будет уникальным для каждого идентификатора t2. Я ожидаю, что эта таблица будет доходить до нескольких миллионов строк. Помимо этих 3 ID, он будет содержать небольшое число столбцов даты или числа.

Мой вопрос в t2 я должен настроить столбец идентификаторов, который t3 будет ссылаться по существу означает, что первичный ключ t3 будет 2 колонки вместо 3, т.е. t3 ID и столбец идентификаторов из t2 , Будет ли это более эффективным? Следует ли индексировать этот столбец идентификатора внутри t2? помочь с присоединениями?

Должен ли я делать что-нибудь еще?

Answer 1

Моя первая мысль касается заявление

... кнопку [t2 | t3] числовой идентификатор будет отправлен приложением внешнего интерфейса ...

Если вы генерации уникальных идентификаторов для использования в базе данных я бы предложил вам дать базу данных сгенерировать числа. Если вы не можете быть абсолютно уверены приложение не будет генерировать повторяющиеся идентификаторы.

В ответ на ваш комментарий, вот разницу при использовании суррогатных ключей (если я понял вашу структуру таблицы правильно)

 
    +----+ +----+ +----+ 
    | | | | | | 
    | t1 +---+ t2 +---+ t3 | 
    | | | | | | 
    +----+ +----+ +----+ 

keys: t1.id t1.id t1.id 
       t2.id t2.id 
         t3.id 

Изменения к суррогатным ключам не стало менять t1 (нет необходимости); t2 также останется прежним, но вам нужно будет изменить t2.id как номер строки на первичный ключ уникального номера [pk]. Проблема заключается в том, что вам нужно будет сохранить «номер строки» в качестве другого поля в таблице.

Главным отличием будет t3, которому нужен только t2.pk и собственный идентификатор строки, а не все три идентификатора таблицы.

 
     +----+ +----+ +----+ 
     | | | | | | 
     | t1 +---+ t2 +---+ t3 | 
     | | | | | | 
     +----+ +----+ +----+ 

keys: t1.id  t2.pk t2.pk 
       t1.id t3.pk 

Будет ли это лучше? Я не уверен. Это также зависит от типа и частоты запросов, которые вы используете против таблиц (см. Мой комментарий к вашему вопросу).

Если вы в основном запрос по id то первый макет будет лучше - подстановки строк в t3 без присоединиться к t2 или t1. Но если вам нужна информация из этих других таблиц для выполнения ваших поисков, суррогатная ключевая структура может сделать ваши объединения менее подробными.

В конечном счете, это преждевременная оптимизация (с точки зрения производительности запросов), потому что вы не будете знать, что лучше всего работает, пока вы ее не реализуете.

Answer 2

Обычно я создаю для этого первичные ключи идентификации, и это будет кластеризованный индекс.

У меня не было бы t2 или t3 с идентификатором, который является составным, а отдельным полем и устанавливает ограничение внешнего ключа.

Кластеризованный индекс и внешний ключ будут всем необходимым индексировать (для объединений). Вам могут потребоваться дополнительные индексы на основе ваших запросов.

Я установил это на столах со стоми миллионов строк и получаю результаты запроса менее чем за 1 секунду.