Цитата:
Сообщение от
Vadik
Во-первых - не зря выше про выравнивание спросили.
Выравнивание - right, как и на большинстве основных справочников в системе.
Цитата:
Сообщение от
Vadik
Во-вторых, начали c
X++:
SELECT LEDGERTRANS EXISTS JOIN
закончили
, у которого при наличии покрывающего индекса план выполнения будет значительно отличаться от исходного
count(recId) был приделан для того, что бы оценить время выполнения запроса сиквелом полностью, т.к. вроде при обычном select'е выбирается только часть записей, определяемая всякими параметрами, кэшем и т.д. А в дальнейшем, при необходимости, довыбираются остальные.
Цитата:
Сообщение от
Vadik
Кто сильнее - кит или слон?
Такая постановка вопроса не имеет смысла, так как единственный ответ на него - 'it depends'
.........
Все равно мне вариант с EXISTS JOIN не нравится - он будет сильно зависеть от условий запроса (наполнения промежуточной таблицы), т.е. менее предсказуем в дальнейшем. Если промежуточная таблица статичная (настроечная) - такой вариант имеет право на существование, если ее перед каждым запросом придется наполнять (не забываем про многопользовательскую работу) - отказать
Позволю себе краткое резюме
...
Получается, что если 2-ая таблица (param), определяющая выборку записей из 1-ой (trans), - настроечная (является статической, и содержит не более 10-15 записей), то вариант с exists join значительно предпочтительнее использования like с маской, так как дает ощутимый прирост производительности (от в 1,5 до более чем в 10 раз).