Найгірші методи (MS SQL Server) – Частина 1 дуже довгої серії!

У нашій роботі ми витрачаємо багато часу на розмови про "Кращих методах" – способи зробити що-то, що протягом довгого часу, виявляється найбільш ефективним (або точним, або яким-небудь ще). Є пара проблем, пов'язаних з Кращими методами. Перша – це те, що немає ніякої "книги" про них; вони розкидані по сотням книжок і веб сайтів, і часто вам потрібно лише одне речення з усієї цієї інформації. Інша проблема полягає в тому, що оцінка того, що вважати Кращим методом, не цілком зрозуміла, тому що це залежить від вашого ставлення до вирішення проблеми, вашого досвіду та вашої ситуації. Нарешті, іноді Кращі методи (Давайте використовувати скорочення ЛМ) можуть бути пасткою, що заважає вам шукати підходи, які кидають виклик ЛМ, але могли б стати ідеальним рішенням вашої проблеми.


Ще цікаво?


На наших дискусійних форумах і в електронній пошті, яку я отримую, зустрічається багато питань про те, як зробити те чи інше. У таких обговореннях цікаво брати участь – зазвичай людини, що задає питання, просто турбує необхідність вирішити проблему, а не ЛМ, – але часто виявляється, що ЛМ повинен був, в першу чергу, уникати самого питання!


Інше, що часто зустрічається, – це те, що питання, яке задає читач, зачіпає велику проблему, яку я називаю Найгірші Методи (ГМ). Вони намагаються вирішити неправильну завдання – ми ще доберемося до деяких коротких прикладів цього. Розмірковуючи про це, мені спало на думку, що багато читачів могли б отримати користь з обговорення того, чому деякі речі є дуууже поганими. І ось що цікаво, – Я думаю, що ХМ наносять на карту найкоротший шлях до вирішення проблеми. Я кажу це, оскільки впевнений, що якщо дати молодшому розробнику або адміністратора баз даних завдання, то в 8-ми випадках з 10-ти їх рішення будуть примітивні.


Перш ніж почати, хочу попередити, що я не насміхаюсь над тими, хто ставить питання. Слід відзначити виняткову ступінь ввічливості на наших дискусійних форумах. Наша місія полягає в тому, щоб допомогти нашим читачам розібратися з проблемами SQL Server, а також проблемами, близько пов'язаними з першими. Якраз питання новачка дають нам чудову можливість навчити читача, який запитав … і всіх тих, хто читав обговорення протягом і після дискусії.


У наступні місяці я буду звертатися до багатьох пунктах ХМ, але сьогодні давайте почнемо з простого – використання угорської нотації (Hungarian Notation) для іменування стовпців. Якщо Ви не знайомі з угорською нотацією, прочитайте статтю в MSDN (http://support.microsoft.com/support/kb/articles/Q173/7/38.ASP). У двох словах, це спосіб позначення ваших змінних так, щоб вони включали як опис, так і інформацію про тип даних.


Declare @LoopCounter int

Declare @iLoopCounter int


У цьому прикладі, друге опис використовує угорську нотацію – я використовував префікс "i", щоб вказати, що це цілочисельне значення. Як тільки Ви звикаєте до цієї нотації, вона починає в значній ступеня економити ваш час, тому що Вам вже не потрібно перегортати код тому, щоб подивитися тип змінної. З іншого боку, коли вам необхідно змінити тип на bigint, у Вас є вибір:


Declare @biLoopCounter bigint

Declare @iLoopCounter bigint

Ви можете використовувати пошук і заміну імені змінної у Вашій процедурою для відображення факту зміни типу (ЛМ) або ж змінити лише тип даних (ГМ). Звичайно, якщо Ви не використали угорську нотацію, тоді Ви тільки змінюєте тип даних. Я часто використовую VB, і угорська нотація там досить звичайна, через деякий час це стає зручним, і рідкісні додаткові зусилля щодо зміни імен змінних з надлишком відшкодовується перевагою в легкості читання. Я залишаю на ваш розсуд вирішення того, чи є угорська нотація ЛМ в кодуванні.


Тепер давайте подивимося на щось більш близьке нам – на таблицю! Візьміть крутого програміста на VB, який використовує угорську нотацію для своїх списків продуктових магазинів?


iQuantity (int)

bIsComplete (bit)

Це круто, чи як? Той же самий синтаксис іменування, ті ж самі переваги в легкості читання. Так чому я назвав би це ХМ? Створіть кілька таблиць з використанням такої системи іменування. Потім побудуйте кілька подань і збережених процедур, пару для користувача функцій (UDF), плюс три або чотири розробника протягом місяця писали програми для цієї бази. Тепер ви вирішили, що бітове значення для IsComplete не буде працювати, оскільки значень стану виявилося більше двох, і Ви збираєтеся змінити тип даних на tinyint. Збираєтеся змінити ім'я стовпця? І не думайте! Це занадто дорого для такого незначного виправлення.

Andy Warren (Оригінал: Worst Practices – Part 1 of a Very Long Series!)
Переклад: Моісеєнко С.І.
Оригінал перекладу


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


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

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

Ваш отзыв

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

*

*