Худшие методы (MS SQL Server) - непродуманное добавление столбца!

Источник: SQL exercises

Забавно, как незначительные вещи могут выбить нас из колеи. Остановитесь и минуту подумайте - если один из ваших разработчиков просит добавить столбец в таблицу, сколько усилий вы прикладываете (или сколько их следует приложить), чтобы убедиться в том, что это изменение не будет ничего нарушать? Вам следует поразмыслить над следующими моментами:

  • Реплицируется ли таблица? Если так, то должен ли новый столбец быть добавлен к статье и отправлен подписчикам, или лишь добавлен к основной таблице?
  • Имеются ли на таблице триггеры? Если Вы вставляете целую строку в таблицу, хранящую некоторую историю модификации данных, то Вы должны будете сначала изменить эту таблицу истории, затем "оперативную" таблицу, а потом изменить триггеры.
  • Должен ли столбец быть включен в какие-нибудь представления, которые имеют ссылку на эту таблицу? Если представления используют запрос типа 'select *', Вы должны будете выполнить sp_refreshview, чтобы эти изменения вступили в силу. Если столбцы задаются явно, Вы должны будете изменить представления, чтобы добавить новый столбец.
  • Соответствует ли новый столбец принятому соглашению об именовании?
  • Имеет ли столбец значение по умолчанию и должны ли существующие строки получить это значение?
  • Допускаются ли NULL-значения?
  • Не превысит ли добавление столбца допустимый максимальный размер строки?
  • Если Вы реплицируете таблицу, не превысит ли это добавление предельное значение на 256 столбцов для транзакционных статей? Или предел для слияния - 246 столбцов/6000 символов?
  • Является ли столбец битовым? Особенность некоторых версий Access (см. 280730) состоит в том, что все битовые столбцы были полностью заполнены - никаких NULL-значений - или Вы получите сообщение об ошибке, "Эта запись была изменена другим пользователем после того, как Вы начали редактировать ее."
  • Должен ли он иметь ограничение на уникальность (UNIQUE)? Иметь индекс?
  • Используется ли подходящий тип данных? В частности, использование типа float (число с плавающей точкой) может привести к проблемам при обновлениях, выполняемых при помощи рекордсетов DAO/ADO с использованием оптимистической блокировки, поскольку ошибки округления выглядят так, как будто запись была изменена.
  • Используется ли еще где-либо в той же базе данных столбец с тем же именем? Это происходит довольно часто, когда Вы добавляете внешний ключ. К сожалению, если где-то имеются ссылки на обе таблицы в операторе select, но имя столбца не уточнено именем таблицы или алиасом, Вы получите ошибку "ambiguous column name" (неоднозначное имя столбца).
  • Должно ли быть задано ограничение внешнего ключа? Если так, должны ли допускаться каскадные операции обновления/удаления?

Andy Warren (оригинал: Worst Practice - Adding a Column Without Thinking!)
Перевод: Моисеенко С.И.
Оригинал перевода


Страница сайта http://test.interface.ru
Оригинал находится по адресу http://test.interface.ru/home.asp?artId=4893