На главную страницу
Худшие методы - Часть 1 очень длинной серии!
Andy Warren (оригинал:
Worst Practices - Part 1 of a Very Long Series!)
Перевод Моисеенко С.И.
В нашей работе мы тратим много времени на разговоры о "Лучших методах" -
способах сделать что-то, что в течение долгого времени, оказывается самым
эффективным (или точным, или каким-либо еще). Есть пара проблем, связанных с
Лучшими методами. Первая - это то, что нет никакой "книги" о них; они
разбросаны по сотням книг и веб сайтов, и часто вам нужно лишь одно предложение
из всей этой информации. Другая проблема заключается в том, что оценка того,
что считать Лучшим методом, не вполне ясна, т.к. это зависит от вашего
отношения к решению проблемы, вашего опыта и вашей ситуации. Наконец, иногда
Лучшие методы (давайте использовать сокращение ЛМ) могут быть западней,
мешающей вам искать подходы, которые бросают вызов ЛМ, но могли бы стать
идеальным решением вашей проблемы.
Еще интересно?
На наших дискуссионных форумах и в электронной почте, которую я получаю,
встречается много вопросов о том, как сделать то или иное. Интересно
участвовать в таких обсуждениях - обычно человека, задающего вопрос, просто
заботит необходимость решить проблему, а не ЛМ, - но часто оказывается, что ЛМ
должна бы, в первую очередь, избегать самого вопроса!
Другое, что часто встречается, - это то, что вопрос, который задает читатель,
затрагивает большую проблему, которую я называю Худшие Методы (ХМ). Они
пытаются решить неправильную задачу - мы еще доберемся до некоторых кратких
примеров этого. Размышляя об этом, мне пришло в голову, что многие читатели
могли бы извлечь пользу из обсуждения того, почему некоторые вещи являются
оооочень плохими. И вот что интересно, - я думаю, что ХМ наносят на карту самый
короткий путь к решению проблемы. Я говорю это, поскольку уверен, что если дать
младшему разработчику или администратору баз данных задачу, то в 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. Собираетесь изменить имя столбца? И не думайте! Это
слишком дорого для такого незначительного исправления.
Вы согласны со мной? Или нет?? Можете обсудить это на форуме.
03.12.2004
На главную страницу