vandalsvq писал(а) 10. Сентября 2009 :: 20:14:Я ушел спать, пора бы уже. Предлагаю дискуссию закончить, и я сделаю так как я вижу решение проблемы (дополнительным методом в классе для оптимизации).
Если оно тебя не устроит поговорим дальше, обсудим и продолжим работу над ошибками.
А счас я спать, а завтра я пить, а в субботу я тоже пить. Но тут я буду, периодически, эпизодами, так что пишите коли что
Ну, это понятно, ты - автор, пиши, как хочешь, дело хозяйское.
Запросы с виртуальными таблицами составляют чуть менее чем приблизительно 48.44% от всех запросов
. Я вот полез в класс именно с таким вот запрсом:
ТекстЗапроса = "
|ВЫБРАТЬ
|$КатегорииЦен.Наименование КАК Категория,
|$ПоследнееЗначение.Цены.Цена($Цены.ТекущийЭлемент, :РабочаяДата) КАК [Цена $Число]
|ИЗ Справочник.КатегорииЦен КАК КатегорииЦен $nolock
|ВНУТРЕННЕЕ СОЕДИНЕНИЕ Справочник.Цены Цены $nolock По $Цены.Категория = $КатегорииЦен.ТекущийЭлемент
|ГДЕ
|$Цены.Владелец = :ТекущийЭлемент
|И $КатегорииЦен.ПометкаУдаления = 0
|И $Цены.ПометкаУдаления = 0
|УПОРЯДОЧИТЬ $КатегорииЦен.Наименование
|";
Дважды его парсить - смысла нет, вреда от "неподстановки" параметров в SQL версии - тоже. А вызывается он часто, очень часто - из функции к УстДоступность.
У меня баз в работе с пару десятоков. Поэтому читабельность кода для меня на первом месте - через пол-года очень тяжело вспомнить, что же ты писал, особенно, если код нечитабельный (а к такому виду он, как правило, приходит после оптимизаций по скорости).
Оставь переключатель на парсинг доп. условий и переменных, не документируй. Несколько дополнительных строк погоды не сделают, на общей скорости класса это не скажется никак, на надежности - тоже. Кому нужно, тот будет пользовать под свою ответственность, кому не нужно - не будет. Делов-то.
Страницы: 
Класс "ПрямойЗапрос" (число прочтений - 304998 )
