Вопрос знатокам сиквела

[CDR]

Цитата:

Сообщение от Vadik

... ничего, что я на ТЫ? ...

конечно ничего, особенно учитывая, что бывшие коллеги

[belugin]

а планы запросов можешь привести?

[Владимир Максимов]

Цитата:

Сообщение от CDR

У меня, как я уже писал, exists join "сделал" like более чем в 10 раз

Абсолютные величины времени исполнения какие? Если разница в 1...2 секунды, то это в пределах погрешности.

Еще попробуй EXISTS JOIN заменить на INNER JOIN

[CDR]

Цитата:

Сообщение от Владимир Максимов

Абсолютные величины времени исполнения какие? Если разница в 1...2 секунды, то это в пределах погрешности.

Еще попробуй EXISTS JOIN заменить на INNER JOIN

У меня на 200 000 записей время было около секунды, поэтому, собственно и пользовался функцией WinAPI::getTickCount() для большей точности вместо timeNow(). Сомнительно, что устойчивая разница в 10 раз является погрешностью. Меня больше интересует exists join, но как вариант, можно еще поиследовать и INNER JOIN

[Alexius]

Вопросы для тестового примера:
1. В какую сторону сделано выравнивание поля id ?
2. Какая версия SQL сервера ?
3. Какой Collation установлен на базе ?

[Vadik]

Цитата:

Сообщение от CDR

Вопрос не в том, какие варианты возможны?... как это лучше реализовать?... и т.п.
Вопрос в том, что быстрее exists join или like.

Кто сильнее - кит или слон?

Такая постановка вопроса не имеет смысла, так как единственный ответ на него - 'it depends'

Твой тест не на 100% корректен
Во-первых - не зря выше про выравнивание спросили. В зависимости от настроек выравнивания EDT выравнивания для LIKE могут различаться. Более адекватным для сравнения exists join с промежуточной таблицей был бы запрос (Trans.Id == 1 || Trans.Id == 2 || .. )
Во-вторых, начали c

SELECT LEDGERTRANS EXISTS JOIN

закончили

SELECT COUNT(RECID)

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

У меня на LEDGERTRANS около 5 млн записей (правда, LEDGERTRANS индексирован нестандартно ) EXISTS JOIN с временной таблицей шуршит примерно на 60% (350мс против 600мс) быстрее

Все равно мне вариант с EXISTS JOIN не нравится - он будет сильно зависеть от условий запроса (наполнения промежуточной таблицы), т.е. менее предсказуем в дальнейшем. Если промежуточная таблица статичная (настроечная) - такой вариант имеет право на существование, если ее перед каждым запросом придется наполнять (не забываем про многопользовательскую работу) - отказать

[CDR]

Цитата:

Сообщение от Vadik

Во-первых - не зря выше про выравнивание спросили.

Выравнивание - right, как и на большинстве основных справочников в системе.

Цитата:

Сообщение от Vadik

Во-вторых, начали c

SELECT LEDGERTRANS EXISTS JOIN

закончили

SELECT COUNT(RECID)

, у которого при наличии покрывающего индекса план выполнения будет значительно отличаться от исходного

count(recId) был приделан для того, что бы оценить время выполнения запроса сиквелом полностью, т.к. вроде при обычном select'е выбирается только часть записей, определяемая всякими параметрами, кэшем и т.д. А в дальнейшем, при необходимости, довыбираются остальные.

Цитата:

Сообщение от Vadik

Кто сильнее - кит или слон?

Такая постановка вопроса не имеет смысла, так как единственный ответ на него - 'it depends'
.........
Все равно мне вариант с EXISTS JOIN не нравится - он будет сильно зависеть от условий запроса (наполнения промежуточной таблицы), т.е. менее предсказуем в дальнейшем. Если промежуточная таблица статичная (настроечная) - такой вариант имеет право на существование, если ее перед каждым запросом придется наполнять (не забываем про многопользовательскую работу) - отказать

Позволю себе краткое резюме ...
Получается, что если 2-ая таблица (param), определяющая выборку записей из 1-ой (trans), - настроечная (является статической, и содержит не более 10-15 записей), то вариант с exists join значительно предпочтительнее использования like с маской, так как дает ощутимый прирост производительности (от в 1,5 до более чем в 10 раз).

[Alexius]

Цитата:

Сообщение от CDR

Выравнивание - right, как и на большинстве основных справочников в системе.

При выравнивании вправо like производит полное сканирование таблицы и выиграть у других вариантов у него нет шансов. Можете попробовать использовать вместо like условия >= <= , предложенные выше.

[belugin]

Цитата:

Сообщение от Alexius

При выравнивании вправо like производит полное сканирование таблицы и выиграть у других вариантов у него нет шансов. Можете попробовать использовать вместо like условия >= <= , предложенные выше.

А в этом случае оно будет работать правильно?

[Alexius]

Цитата:

Сообщение от belugin

А в этом случае оно будет работать правильно?

В смысле правильных результатов, то да. С точки зрения производительности, тоже должно быть не хуже чем с дополнительной таблицей, т.к. прямое указание критерия в запросе на SQL преобразуется в конкретное значение с ведущими пробелами, а при использовании like используется ltrim, исключающий использование индексов.

[belugin]

но тогда получается, что результат будет неэквивалентен like

[Alexius]

Цитата:

Сообщение от belugin

но тогда получается, что результат будет неэквивалентен like

В общем случае ДА, но для конкретного примера эквивалентен.