Здравствуйте, Serginio1, Вы писали:

S> Поиск на == и <= используют один и тот же алгоритм половинного деления по индексу.

Это при запросе одиночного значения.
При джоинах на индексе этот алгоритм для каждой строчки выполняется не в "чистом" виде, а лишь по интервалу от предыдущего найденного значения (соединяются-то сортированные наборы), т.е. в случае простого join== всегда сводится к операции перехода на следующую строку, если текущая строка основного ключа не подошла строке внешнего ключа.


S>Сложность одинакова. Только при курсе на каждый день нужно заполнять все дни (выходные, праздники когда торги не проходят), что увеличивает размер таблицы и индекса

Ну как же одинаковая, если в случае нестрого равенства надо сравнивать даты у двух соседних строчек? ))
Это совсем другой алгоритм перебора строк.

Если первый алгоритм всегда присутствует в базе выполненым на "железячном" уровне, то второй выполняется по классике жанра — через честные параметрические сканы таблиц и запуски "скриптов" проверки условий (привет метаинформации и всему, что с ней связано), бо таких различных условий, отличных от базовых inner и outer join — их потенциально бесконечный комбинаторный набор.

Здравствуйте, Serginio1, Вы писали:

S> Поиск на == и <= используют один и тот же алгоритм половинного деления по индексу.

Это при запросе одиночного значения.
При джоинах на индексе этот алгоритм для каждой строчки выполняется не в "чистом" виде, а лишь по интервалу от предыдущего найденного значения (соединяются-то сортированные наборы), т.е. в случае простого join== почти всегда сводится к операции перехода на следующую строку, если текущая строка основного ключа не подошла строке внешнего ключа.


S>Сложность одинакова. Только при курсе на каждый день нужно заполнять все дни (выходные, праздники когда торги не проходят), что увеличивает размер таблицы и индекса

Ну как же одинаковая, если в случае нестрого равенства надо сравнивать даты у двух соседних строчек? ))
Это совсем другой алгоритм перебора строк.

Если первый алгоритм всегда присутствует в базе выполненым на "железячном" уровне, то второй выполняется по классике жанра — через честные параметрические сканы таблиц по индексам и запуски "скриптов" проверки условий (привет метаинформации и всему, что с ней связано), бо таких различных условий, отличных от базовых inner и outer join — их потенциально бесконечный комбинаторный набор.