Версия для печати

На главную страницу

Худшие методы - объекты, не принадлежащие DBO

На прошлой неделе я опубликовал статью о том, что я назвал "Худшие Методы", или ХМ для краткости. Это понятия, которые находятся в другом конце спектра от "Лучших методов" (ЛМ), хотя я замечаю, что их используют слишком часто. Моя цель в этой серии статей состоит в том, чтобы выявить некоторые из этих методов и обсудить, почему они не хороши. Если мы не всегда можем применять лучшие методы из-за ограниченности во времени и других практических дел, нам следует, по крайней мере, стараться избегать наихудших ошибок!

На этой неделе я хотел бы обсудить вопрос принадлежности объекта. По моему мнению, иметь для объекта ЛЮБОГО другого собственника кроме DBO - худший способ! Теперь давайте поговорим о том, почему это плохо.

Для тех из Вас, кто плохо знаком с SQL или возможно не знаком только с этим понятием, поясню, что каждый объект (таблица, представление, хранимая процедура и т.д) в SQL имеет владельца. Вы становитесь владельцем объекта, будучи действительным пользователем базы данных, имеющим разрешение на создание объектов, после того, как фактически создаете объект. Легко узнать, кто является собственником объекта с помощью Enterprise Manager, где есть столбец, в котором указывается владелец каждого объекта. В результате Вы можете получить многочисленные объекты с одним и тем же именем.

Даже если Вы не знаете об этом, Вы используете принадлежность, когда пишите оператор select, который ссылается на таблицу, например, следующим образом:

Когда этот оператор выполняется, SQL сначала пытается выполнить оператор в предположении, что именно Вы являетесь собственником данного объекта. Это "Вы" определяется тем, как Вы подключаетесь к базе данных. Скажем, в текущем подключении я - пользователь 'wp'. Это означает то, что SQL пробует сделать так:

Если такой объект не существует, то будет сделано следующее:

Требуется немного работы, чтобы выявить правильный объект, и это занимает немного времени. Вы можете привести аргумент, что следует всегда квалифицировать объекты именем владельца, но это были бы лучшие методы, и пока я оставляю их другим!

Вы и я знаем, что мы не квалифицируем все объекты. Это занимает время, делает код больше и, возможно, немного менее читабельным. Но какова основная причина? Когда мы писали код, все принадлежало dbo. Так что мы получим, добавляя dbo. к каждому имени объекта?

Немного головной боли.

Возьмем ситуацию, когда Вы позволили объектам принадлежать кому-то другому отличному от dbo. Вы получили многочисленные копии различных таблиц и хранимых процедур, в том числе две таблицы Categories, одну принадлежащую dbo, а другую принадлежащую wp. Ваша команда разработчиков пишет небольшое приложение, которое использует таблицу Categories ..., одну принадлежащую dbo, хотя они полностью не квалифицируют объект. Приложение прекрасно работает при тестировании. Вы устанавливаете приложение для пользователя WP, оно запускается, но WP сообщает, что он видит только пять категорий, в то время как пользователь Bp, который сидит напротив, видит восемь? Вы можете проверять весь код целый день и не найти ошибку. BP и WP используют различные таблицы, но это скрыто от разработчика!

Изобретательно? Конечно. Но возможны различные вариации этой проблемы.

Давайте перейдем ко второй части, почему идея цепочек владения такая плохая. Если Вы сдавали экзамены по SQL, то знаете, что MS любит включать один или два вопроса о цепочках владения. Избегайте их! Создавайте ваши разрешения (permissions) настолько простыми и ясными, насколько сможете. Снова для тех, кто не знаком с цепочками владения, - это процесс, который SQL должен пройти, чтобы выяснить, можно ли разрешить пользователю доступ к объекту/данным. Пока все объекты принадлежат одному и тому же пользователю, процесс прост. Как только цепочка владения "разрывается", SQL вынужден делать больше проверок. Books Online дают довольно хорошее объяснение, сделайте поиск по "Ownership Chains".

Фактически то, что несколько разработчиков или администраторов баз данных намеренно используют собственность объекта, обычно случается по ошибке. Вы можете воспрепятствовать этому либо не предоставляя пользователям разрешений на создание объектов, если они не являются членами роли db_owner, либо позволяя им это, но затем используя sp_changeobjectowner, чтобы сделать dbo владельцем прежде, чем установите код. Я считаю, что из этих двух решений лучшим является первое.

Вы согласны со мной? Или считаете, что я не прав? В любом случае давайте это обсудим - опубликуйте свои комментарии на форуме.

12.11.2004

На главную страницу

  Версия для печати