Это третья статья в серии статей, посвященной Худшим методам (см. "Худшие методы - часть 1 очень длинной серии!" и "Худшие методы - объекты, не принадлежащие DBO"), которые пока вызвали довольно мало откликов читателей. Не каждый пока соглашается со мной, однако, похоже, что я не единственный, кто видит много "плохих" методов повсеместно.
Итак, давайте поговорим еще об одном худшем методе - присутствии первичного ключа НЕ на КАЖДОЙ таблице и использовании кластерного ключа НЕ на КАЖДОЙ таблице.
Я думаю, что в 9-ти случаях из 10, это происходит только по ошибке. Если Вы создаете таблицы в Enterprise Manager и щелкаете по иконке первичного ключа на панели инструментов, это сразу делает столбец первичным ключом и создает на нем кластерный индекс. Это не обязательно лучшее использование кластерного индекса, но это лучше чем ничего. Если Вы создаете таблицы в Query Analyzer, Вам решать, выполнять ли код TSQL, чтобы создать первичный ключ и кластерный индекс (или переключиться в EM, чтобы там выполнить эту часть работы).
Вам решать кто, администратор базы данных или старший разработчик, должен отлавливать эти ошибки до того, как они попадут в конечный продукт. Обязательно следует удостовериться, что ваши разработчики понимают, насколько важны эти моменты; я думаю, что иногда мы падаем впросак, полагая, что каждый ЗНАЕТ, почему это важно. Не предполагайте, спрашивайте. Если они знают хорошо, но просто забыли сделать, то следует мягко напомнить о важности этих моментов. Если они не знают это хорошо, то самое время об этом узнать.
Становится интересным (во всяком случае, мне!), когда кто-то пытается убедить меня, что они не нуждаются в первичном ключе. Подождите-ка, наличие первичного ключа - одно из основных понятий, так почему он Вам не нужен? В ответ я слышу пару аргументов, давайте посмотрим, имеют ли они хоть какой-нибудь вес.
Первый аргумент, что таблица является настолько маленькой, что индекс не будет использоваться в плане выполнения запроса. Весьма возможно, что это так. Ну и что? Если Вы делаете предположение, что таблица всегда будет маленькой, что случится, когда она вырастет? Будет ли разработчик (или администратор базы данных) помнить: "Эй, я должен добавить индекс к этой таблице"? Более вероятно, что это будет установлено только тогда, когда возникнет проблема с производительностью. Что касается меня, то я люблю строить их сразу же. Зачем разрешать проблему позже, если я могу избежать ее сейчас? Сколько времени требуется, чтобы создать первичный ключ или кластерный индекс по сравнению с тем, чтобы выяснять позже, почему возникли проблемы производительности? Хотя более важным вопросом по сравнению с планом выполнения запроса является вопрос о целостности данных. Отсутствие первичного ключа может привести к фатальному отказу. Уверен, что Вы не будете добавлять дубликаты в таблицу, но что случится, если это сделает кто-то другой? Сколько времени потребуется, чтобы это выяснить?
Другой аргумент, что это временная таблица, и потому правила здесь действительно не применяются. По сравнению с первым аргументом, я полагаю, здесь есть некоторая доля истины. Не большая, но есть! Думаю, что самый большой довод в пользу этого аргумента заключается в том, что во многих случаях, когда Вы используете временную таблицу, в настоящее время Вы можете (и, вероятно, должны) использовать переменную табличного типа (доступную с версии SQL 2000), который позволяет Вам определить только структуру, но не индексы. Помните только, что никогда не будет ошибкой создание первичного ключа в таблице, временная она или нет.
Создание первичного ключа (и/или кластерного индекса) не является исключительно необходимым для многих ситуаций типа временных таблиц, справочных таблиц (lookup tables) и даже таблиц истории/ревизии. Вздор. Да, каждый индекс, каждое ограничение, каждое значение по умолчанию, каждый триггер несколько увеличивает накладные расходы. Должны ли мы стремиться минимизировать эти накладные расходы в нашем проекте? Всегда. Но никогда за счет целостности данных. Если ваша система загружена так, что Вы волнуетесь о накладных расходах из-за наличия первичного ключа в таблице, у Вас серьезные проблемы. Хорошо, что только один первичный ключ и кластерный индекс может быть создан для каждой таблицы, поэтому довольно трудно избежать их использования!
Наконец, "я не нуждаюсь в кластерном индексе". Хорошим примером этого могла бы стать справочная таблица, которая содержит название штата и его аббревиатуру. Вы собираетесь выполнять поиск единственной записи, и никогда - диапазона, когда преимущество кластерного индекса является несомненным. Вы также не собираетесь иметь много индексов, вероятно один на названии и один на аббревиатуре, где индекс обеспечит необходимые данные, при этом не требуется выполнять поиск по таблице, чтобы найти другие биты информации, связанные с найденной строкой. Справедливо ли данное утверждение для этого примера? Я думаю да. С другой стороны, каковы накладные расходы на добавление кластерного индекса? Поскольку обновление здесь не предполагается, данные представляют собой индекс, то расходы весьма незначительны.
Моя рекомендация начинающим разработчикам довольно проста. Каждая таблица получает как первичный ключ, так и кластерный индекс. Это, возможно, не "лучший" метод, но достаточно хорошая отправная точка, просто добавить столбец identity, называемый идентификатором строки (rowid), и сделать его первичным ключом и кластерным индексом. По мере роста мастерства Вы сможете рассмотреть и более передовые альтернативы.
Я хотел бы поблагодарить тех читателей, которые нашли время, чтобы добавить комментарий к моим двум первым статьям. Эти комментарии, как тех, кто соглашается, так и тех, кто не соглашается, дают ценное дополнение ко всем статьям, опубликованным SQLServerCentral.com. Увидеть, что другие люди думают о содержании, действительно полезно особенно для новых разработчиков и администраторов баз данных, т.к. имеется множество различных мнений по схожим проблемам, и трудно узнать, какое из них является правильным. Согласны Вы или нет, почему бы ни сообщить всем о своем мнении?
Andy Warren (оригинал: Worst Practices - Not Using Primary Keys and Clustered Indexes)
Перевод: Моисеенко С.И.
Оригинал перевода