Тема: if (a == true)
Показать сообщение отдельно
Старый 13.06.2012, 09:39   #35  
fed is offline
fed
Moderator
Аватар для fed
Ex AND Project
Соотечественники
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
2,913 / 5736 (197) ++++++++++
Регистрация: 13.03.2002
Адрес: Hüfingen,DE
Цитата:
Сообщение от mayk Посмотреть сообщение
Это вообще-то является BP
If a select statement is local to a method, use a field list to increase performance. If you use
a select or a while select statement and the size of the fields that are used total less than 50
percent of the total record size, a warning appears if you do not use a field list.

и существенно ускоряеет выполнение запросов, так как в сеть не пихается туча данных, из которых не используется и половина.
Ну это весьма сомнительная оптимизация и еще один пример того, почему я так слабо обращаю внимание на BP. В большинстве случаев, затраты на перекачку данных по сети пренебрежимо малы по сравнению с затратами на чтение с диска. С точки зрения производительности, выгодно указывать список полей если:
  1. Есть покрывающий индекс состоящий из полей в списке выбора и условия where. (Надо помнить что все индексы неявным образом включают поля кластерного индекса. Так что некластерный индекс может покрывать больше полей чем вы ожидали.)
  2. Если в таблице есть мемо-поля (контейнеры или строковые поля с длинной (Memo)). И те и другие долго подгружать и пересылать
  3. Если у вас в таблице много полей (то есть эдак штучек 50). Но мы ведь не делаем таких плохо нормализованных таблиц, правда ведь ?
  4. Ну и я бы пожалуй добавил случай экстремальной оптимизации. Скажем если мы засунули новый запрос в какое-то ключевое место нагруженных алгоритмов - типа закрытия склада,рассчета покрытия или ресурсного планирования, то экономия 3% на перекачку данных, в запросе, который исполняется миллионы раз, может оказаться выгодной
В остальных случаях копеечная экономия на сетевом трафике никогда не окупит те дополнительные риски, которые порождает подобная оптимизация. Как мы все знаем, в реальной жизни, доработки нужны "еще позавчера", времени их продумывать и тестировать ни у кого нету и шансы что после такой оптимизации какая-то логика сильно поломается - очень велики.

Этот пример еще раз подтверждает мою мысль что Аксаптовские Development Best Practice пишутся не для реальных проектов, а для разработки сферического коня в кубе...

Последний раз редактировалось fed; 13.06.2012 в 11:31.