Найгірші методи (MS SQL Server) – об'єкти


На минулому тижні я опублікував статтю про те, що я назвав "Гірші Методи", або ХМ для стислості. Це поняття, які знаходяться в іншому кінці спектру від "Кращих методів" (ЛМ), хоча я помічаю, що їх використовують занадто часто. Моя мета в цій серії статей полягає в тому, щоб виявити деякі з цих методів і обговорити, чому вони не хороші. Якщо ми не завжди можемо застосовувати кращі методи через обмеженість в часі та інших практичних справ, нам слід, принаймні, намагатися уникати найгірших помилок!


На цьому тижні я хотів би обговорити питання приналежності об'єкта. На мою думку, мати для об'єкта БУДЬ іншого власника крім DBO – найгірший спосіб! Тепер давайте поговоримо про те, чому це погано.


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


Навіть якщо Ви не знаєте про це, Ви використовуєте приналежність, коли пишіть оператор select, який посилається на таблицю, наприклад, наступним чином:


select * from Categories

Коли цей оператор виконується, SQL спочатку намагається виконати оператор у припущенні, що саме Ви є власником даного об'єкта. Це "Ви" визначається тим, як Ви підключаєтеся до бази даних. Скажімо, в поточному підключенні я – користувач "wp". Це означає те, що SQL пробує зробити так:


select * from wp.Categories

Якщо такий об'єкт не існує, то буде зроблено наступне:


select * from dbo.Categories

Потрібно небагато роботи, щоб виявити правильний об'єкт, і це займає небагато часу. Ви можете навести аргумент, що потрібно завжди кваліфікувати об'єкти ім'ям власника, але це були б кращі методи, і поки я залишаю їх іншим!


Ви і я знаємо, що ми не кваліфікуємо всі об'єкти. Це забирає час, робить код більше і, можливо, трохи менш легкий для читання. Але яка основна причина? Коли ми писали код, все належало 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 власником перш, ніж встановіть код. Я вважаю, що з цих двох рішень кращим є перше.


Ви згодні зі мною? Або вважаєте, що я не правий? У будь-якому випадку давайте це обговоримо – опублікуйте свої коментарі на форумі.

Andy Warren (Оригінал: Worst Practices – Objects Not Owned by DBO)

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*