Дня доброго.
Лень делать замеры, но, зная аудиторию, придется.

Насколько оптимально SQL делает такую конструкцию?

ВЫБОР КОГДА Таблица.Условие=ИСТИНА ТОГДА
Таблица.ОченьМалоеПоле
Иначе
Таблица.ОченьБольшоеПоле
КОНЕЦ

Смысл в том, что почти вся таблица заполнения полями с Условием=ИСТИНА, а ОченьБольшоеПоле - это nvarchar (поле вне таблицы, в отдельном потоке)

Имеет ли смысл разбивать на Объединение 2-х запросов или SQL достаточно умен, чтобы не лезть за ОченьБольшимПолем?

А план запроса что говорит?

>> поле вне таблицы, в отдельном потоке
чего?

(2) nvarchar же. Строка переменной длины, не может храниться в таблице, так как переменная длина приводила бы к перестроению таблицы при каждом изменении

(1) План запроса не детализируется до колонок, только до строк

(3) прямо интересно стало как там в MS SQL, но всегда полагал что при фиксированном N varchar(N) тупо выделяет по максимуму место плюс метка завершения строки

"Лень делать замеры, но, зная аудиторию, придется. " ветку можно закрывать, автор с порога облил всех...

на работе работы мало?

(3) не претендую на 100% правду, но вроде было так

в основной таблице выделяется 2 колонки
1 - до какого-то разумного размера (например 1000 символов)
2 - идентификатор на таблицу блобов

если фактическая страка влезает в 1000 символов она хранится в основной таблице, если нет то в блобах

индекс по полю с условием есть?

(5) Только если меньше 4000 символов (8000 байт). Все, что выше - уйдет в отдельный поток.

Условие достаточно простое, чтобы оптимизатор его понял, но я за объединение.

(8) 4000 символов для 2-х байтный строк

(0)
по сабжу - главная проблемма такого кода это кривая статистика и неопределенный план запроса, то есть будет "плавать" и скорость и результат в зависимости от последних выборок

(13) Статистика тут не на что не влияет. Мы уже в строке данных. Вопрос - насколько умен SQL, чтобы не читать строку из BLOB, если ему по условию не надо

(14) Да никто не скажет тебе.

Ладно, будем мерить

(14) имхо, он так же умен, как и принятое сравнение по И
если первое отрабатывает дальше не идет

(0) >ОченьБольшоеПоле - это nvarchar

там китайщина с марками?

(14) результат запроса это динамическая вещь, по этому размер фактических данных будет разный для каждой выборки, но вот тип поля результата тут будет что-то типа составного поля, на сколько я понимаю в самом SQL будет все нормально, но вот в клиенте который будет получать эти данные будет не очень...

Скорее всего будешь получать или неопределенный тип или максимальный

(18) нет, это другое

(18) сжатые xml-ки ТТН-ок

Ну вряд ли скл зачитывает оба поля а потом одно отбрасывает

sql сначала выполнит условие

(22) Инфа - 100%, можно не мерить?

(16)[Ладно, будем мерить] в пятницу, накануне майских, иных путей нет =)

(25) Одинесниги постоянно меряются(по пятницам особенно)

(26) ТС-у есть чем мериться, но ему нужен результат, а не процесс

(0) Либо имеет, либо не имеет. Если имеет, но производительности хватает, то не имеет. А если не хватает - то разбиение будет произведено в рамках тикета.
Тонкая грань между грамотным кодом и преждевременной оптимизацией.

Подпишусь

Интересно, но не помешала бы голосовалка, пока вопрос остается открытым

(0) в case же простая логика, до первого истинного операнда. Проверить жешь можно и без поля, тупо в else поставить 1/0.

Если поле BLOB,то оно читается отдельно.
Если нет,то в выборку читается страница,содержащая запись,а потом уже из этой страницы делается выборка,просто для BLOB поля в этой выборке будет BLOB id.

CASE в SELECT, а это предпоследняя операция в запросе (последняя - ORDER)
C учетом (34) CASE будет выполняться уже по полученным данными из FROM WHERE
Я бы проголосовал за UNION - но в зависимости от объема данных.

Скорее всего считает все, а затем сделает расчёт CASE.
Так что я за union,если считываемых страниц для скана таблицы будет значимо меньше, чем страниц для blob поля. Не забываем, что при union серверу надо ещё merge union сделать

Если поле BLOB,то до передачи значения клиенту вместо значения поля будет записано BLOB-ID,а если это обычное поле,то в плане запроса будут перечислены поля,которые нужно выбрать,и запись сразу будет выбираться со всеми полями.
Если будет объединение с условием,то,если условие позволит выбирать по индексу,а не по самой записи,то поможет,если же по самой записи,то точно также,сначала считается вся запись,а потом будет выполнена проверка условия.

(37) а в какой момент происходит передача значений?