firebird IN

← →
d_oleg © (2003-07-21 15:55) [0]

вопрос к знатокам: почему при использовании IN в запрсе не происходит использование индекса по этому полю?

пример:
select NO from SAMPLE_TABLE where NO=1
select NO from SAMPLE_TABLE where NO between 1 and 10
в этих запросах нормально ипользуется индекс и происходит 10 чтений из БД

select NO from SAMPLE_TABLE where NO in (1,2,3,4)
а при таком запросе происходит чтение _всех_ записей из БД.

поле NO проиндексировано

← →
Alexandr © (2003-07-21 15:56) [1]

потомучто.
Так сделано.

← →
d_oleg © (2003-07-21 16:08) [2]

ответ исчерпывающий :-(

← →
Johnmen © (2003-07-21 16:34) [3]

>при использовании IN в запрсе не происходит использование
>индекса по этому полю

Где это видно ?

>и происходит 10 чтений из БД

Как это проверено ?

>происходит чтение _всех_ записей из БД.

Откуда известно ?

← →
d_oleg © (2003-07-21 17:40) [4]

статистика в IBExpert. Насчёт "не используется индекс" я наверное не совсем правильно выразился - чтения показываются как индексированные, но кол-во чтений равно кол-ву записей в таблице.

← →
Sergey13 © (2003-07-21 17:42) [5]

2d_oleg © (21.07.03 15:55)
Когда ты указываешь конкретное значение поля БД ищет это значение в индексе, находит и читает в таблице нужную строку. Когда ты указываешь несколько значений - БД не может сопоставить этот набор значений и значение в индексе. Так что все логично - IN дорогая операция.

← →
d_oleg © (2003-07-21 17:48) [6]

ну видимо так оно и есть... но как-то не логично получается - неужели нельзя делать отработку запроса в несколько проходов?

← →
Sergey13 © (2003-07-21 17:56) [7]

2d_oleg © (21.07.03 17:48)
>ну видимо так оно и есть... но как-то не логично получается - неужели нельзя делать отработку запроса в несколько проходов?
"В несколько" это во сколько. Там иногда может быть подзапрос который возвращает кучу записей - ни одного сервака не хватит.

← →
Johnmen © (2003-07-21 18:14) [8]

>d_oleg © (21.07.03 17:40)

Да, индекс используется в обоих случаях.

>... кол-во чтений равно кол-ву записей в таблице.

Чтений чего ?

>неужели нельзя делать отработку запроса в несколько проходов?

В смысле ?

← →
Alexandr © (2003-07-22 07:19) [9]

запихай свой список в in во временную таблицу.
И сджойни с ней твой запрос.
Такой скорости ты еще никогда не видел!

← →
d_oleg © (2003-07-22 10:40) [10]

да нафига, проще наверное сделать UNION, на несколько запросов разбив...

← →
Alexandr © (2003-07-22 10:43) [11]

а не будет ли это по скорости как и in

← →
d_oleg © (2003-07-22 13:39) [12]

нет, ведб тогда нормально запрос отрабатывает, по индексу

← →
Alexandr © (2003-07-22 14:00) [13]

но запросов то много. Ну и что что каждый по индексу...
union то много.

А вообще список значений для in откуда идет?

← →
d_oleg © (2003-07-22 15:49) [14]

список значений IN? Ну пользователь задаёт. Как раз для случая, когда он из возможных значений может произвольно выбрать n-ое кол-во.

← →
Alexandr © (2003-07-23 10:22) [15]

вот и пусть юзер в таблицу свои значения и вносит.
И теряться ничего не будет при перезагрузке программы. Удобно.
Юзеры тебе за это только спасибо скажут.

← →
d_oleg © (2003-07-23 11:00) [16]

не, такой подход в корне неправильный. Нече базу засорять всякими пользовательскими выборками. Оно это никому не надо.

← →
Alexandr © (2003-07-23 11:09) [17]

ну-ну...
жизнь покажет...
давайте не будем базу засорять и пользовательскими документами и справочниками заодно... Метаданными? тоже пожалуй лучше не засорять ибо толку от них нету...
Вот это будет в корне правильный подход...

← →
d_oleg © (2003-07-23 12:48) [18]

ну зачем же так категорично? Данные в базе должны быть, но вот такие структуры, типа временных таблиц, не всегда оправданы. Условия выборки хранить в базе? Ну давайте тогда и запросы все туда засунем. А запросы на выборку запросов? С ними как? Утрирую конечно. Но к примеру, если есть справочник из нескольких сот наименований и пользователю захотелось получить инф. по десятку из них - стоит ли пихать в базу эту инфу? Она будет накапливаться с ростом кол-ва пользователей, доп. проверки при управлении пользователями (удаление к примеру), удаления при смене параметров запроса, накопление т.о. мусорных страниц и всяческий подобный геморой. Оно того стоит?

← →
Alexandr © (2003-07-23 12:55) [19]

надуманные проблемы.

← →
Sandman25 © (2003-07-23 13:01) [20]

d_oleg © (23.07.03 12:48)

У нас у одних из клиентов неожиданно свет выключают, поэтому при работе в кассе сразу после выбора товара он записывается в БД. После набора всех товаров покупки происходит осуществление проводки и удаление этих товаров из "временной" таблицы. И ничего, никаких проблем не возникало :)

← →
d_oleg © (2003-07-23 13:30) [21]

ну одно дело, когда с покупками работаешь (тут, естественно, всё должно фиксироваться в БД, кстати совсем не обязательно потом покупки из заказа удалять, просто можно ставить флаг оплаченности заказа, потом эти данные пригодятся), совсем другое - статистику снимаешь. Нужны тогда такие вещи? Ну спорить далее не буду, просто бывают разные ситуации.

← →
Sandman25 © (2003-07-23 13:34) [22]

Я тоже спорить не хочу, только одно замечание себе позволю.
Если использование небольшой таблицы значительно ускоряет получение статистики, то почему бы не воспользоваться.

← →
d_oleg © (2003-07-23 13:37) [23]

да в том-то и дело, что не ускоряет оно, ни значительно, ни как

← →
Sandman25 © (2003-07-23 13:38) [24]

Понятно. Просто мне показалось, что Вы старались добиться использования индекса для ускорения.

← →
d_oleg © (2003-07-23 13:38) [25]

связывание таблиц - в любом случае дело небесплатное, в аспекте ресурсов сервера.

← →
d_oleg © (2003-07-23 13:40) [26]

Естественно пытался. In это делать не позволяет, а UNION - пожалуйста, отрабатывай несколько запросов - и дело с концом.

Убедили.
Все же надеюсь, что Вам не понадобится
select A.*
from A, B
where A.type in (1,2,3,4)
( 5,6,7,8) Убедили.
Все же надеюсь, что Вам не понадобится
select A.*
from A, B
where A.type in (1,2,3,4)
and B.type in (5,6,7,8)
and A.id = B.id
А то слишком много UNION получается

Ну не бывает универсальных решений :-(
Да, к сожеалению и такой аспект имеет место быть.

здесь можно немного с мозгами подойти, between местами использовать, где идентификаторы подряд идут... в-общем вариантов куча.

кто я прикололся?
нет...
Чистая правда.
И настаиваю что это будет самый быстрый способ.
И самый универсальный.
И самый безглючный...
А почему тебе так показалось?

Johnmen © (23.07.03 13:53)

У меня был случай, что надо было один долгий SELECT ускорить.
НаибОльшая скорость оказалась, когда я засунул 3 параметра во временную таблицу (назовем ее T), а потом использовал связку
where A.date1 = T.date1
and B.date2 = T.date2
and C.type = T.type
Так что всякое в жизни бывает :)

>Alexandr © (23.07.03 14:01)

>...настаиваю что это будет самый быстрый способ.

Не факт ! Зависит от многих факторов.

>..самый универсальный.

В чем универсальность ? В выполнении нескольких запросов (в т.ч. и на запись) вместо одного ?

>...самый безглючный...

Чем меньше кода, чем меньше запросов, тем меньше глюков. И ошибок...

>Sandman25 © (23.07.03 15:42)

Не возражаю. Бывают редкие случаи, когда в угоду скорости приносится в жертву всё остальное. Естественно, это м.б. оправдано...

Johnmen © (23.07.03 18:04)

>Чем меньше кода, чем меньше запросов, тем меньше глюков. И ошибок...

Не согласен. Когда-нибудь пытались разобраться в чужом коротком коде на С, написанном "настоящим сишником"?

>Sandman25 © (23.07.03 18:23)

Не знаю, как там у "сишников", я сказал об общем критерии. Справедливом не только в программировании :)

Johnmen

Не будем углубляться в философию, но "меньше" не всегда значит "проще" и тем более "надежнее".

поскольку отклонились от темы, то не стоит к ней возвращаться.
Каждый остался при своем мнении

firebird IN Найти похожие ветки