Найгірші методи (MS SQL Server) – ігнорування первинних ключів і кластерних індексів, Інші СУБД, Бази даних, статті

Це третя стаття у серії статей, присвяченій Найгіршим методам (див. “Найгірші методи – частина 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)
Переклад: Моісеєнко С.І.
Оригінал перекладу


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


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

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

Ваш отзыв

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

*

*