Форум: "Потрепаться";
Текущий архив: 2003.08.18;
Скачать: [xml.tar.bz2];
Вниз
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 - пожалуйста, отрабатывай несколько запросов - и дело с концом.
← →
Sandman25 (2003-07-23 13:43) [27]Убедили.
Все же надеюсь, что Вам не понадобится
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 получается
← →
d_oleg (2003-07-23 13:45) [28]Ну не бывает универсальных решений :-(
Да, к сожеалению и такой аспект имеет место быть.
← →
d_oleg (2003-07-23 13:47) [29]здесь можно немного с мозгами подойти, between местами использовать, где идентификаторы подряд идут... в-общем вариантов куча.
← →
Johnmen (2003-07-23 13:53) [30]По-моему, Alexandr © просто прикололся...:)
>d_oleg ©
Чем же не устраивает IN ?
← →
Alexandr (2003-07-23 14:01) [31]кто я прикололся?
нет...
Чистая правда.
И настаиваю что это будет самый быстрый способ.
И самый универсальный.
И самый безглючный...
А почему тебе так показалось?
← →
Sandman25 (2003-07-23 15:42) [32]Johnmen © (23.07.03 13:53)
У меня был случай, что надо было один долгий SELECT ускорить.
НаибОльшая скорость оказалась, когда я засунул 3 параметра во временную таблицу (назовем ее T), а потом использовал связку
where A.date1 = T.date1
and B.date2 = T.date2
and C.type = T.type
Так что всякое в жизни бывает :)
← →
Johnmen (2003-07-23 18:04) [33]>Alexandr © (23.07.03 14:01)
>...настаиваю что это будет самый быстрый способ.
Не факт ! Зависит от многих факторов.
>..самый универсальный.
В чем универсальность ? В выполнении нескольких запросов (в т.ч. и на запись) вместо одного ?
>...самый безглючный...
Чем меньше кода, чем меньше запросов, тем меньше глюков. И ошибок...
>Sandman25 © (23.07.03 15:42)
Не возражаю. Бывают редкие случаи, когда в угоду скорости приносится в жертву всё остальное. Естественно, это м.б. оправдано...
← →
Sandman25 (2003-07-23 18:23) [34]Johnmen © (23.07.03 18:04)
>Чем меньше кода, чем меньше запросов, тем меньше глюков. И ошибок...
Не согласен. Когда-нибудь пытались разобраться в чужом коротком коде на С, написанном "настоящим сишником"?
← →
Johnmen (2003-07-23 18:33) [35]>Sandman25 © (23.07.03 18:23)
Не знаю, как там у "сишников", я сказал об общем критерии. Справедливом не только в программировании :)
← →
Sandman25 (2003-07-23 18:39) [36]Johnmen
Не будем углубляться в философию, но "меньше" не всегда значит "проще" и тем более "надежнее".
← →
Johnmen (2003-07-23 18:51) [37]>Sandman25 © (23.07.03 18:39)
Наверное, бывают исключения...:) Но я их не знаю...
← →
Alexandr (2003-07-24 08:17) [38]поскольку отклонились от темы, то не стоит к ней возвращаться.
Каждый остался при своем мнении
Страницы: 1 вся ветка
Форум: "Потрепаться";
Текущий архив: 2003.08.18;
Скачать: [xml.tar.bz2];
Память: 0.53 MB
Время: 0.004 c
