Есть таблица A и таблица Б. Структура таблиц одинаковая.
Надо выбрать из таблицы Б записи которых нет в таблице А.
Операций MINUS у нас нет?

Это сообщение отредактировал(а) Zipper - 27.4.2007, 11:40

http://forum.vingrad.ru/forum/topic-146682.html

Это сообщение отредактировал(а) Akella - 28.4.2007, 15:52

А при использовании такого запроса на большой базе (2 млн. записей), у меня он не работал. Как только ограничивал выборку до 200-500 тыс. записей все ок! В FireBird (версия 1.5.3) есть какието ограничения на этот счет?

Это сообщение отредактировал(а) Zipper - 28.4.2007, 05:15

думаю, что нет, просто FB "критично" относится к таким, можно сказать тяжёлым запросам, лучше этот запрос вставить в процедуру

Добавлено через 41 секунду
по идее процедура начинает отдавать записи ещё до того, как выполнится запрос полностью, ну или что-то в этом роде

На полной базе (2 млн.) запрос сразу срабатывает и показывает полное отсутствие таких записей (запрос не зависает), т.е. он вообще ничего не отдает. А на маленькой базе (200-500 тыс.) находит записи.

Бедный сервер да он при 2мил записях задымится от такого запроса должен был, но видимо разработчики это учли и поставили блокировку. 
А теперь разберемся по порядку:
1. Нам нужно выбрать все уникальные записи из таблицы B, мы вдруг начинаем просматривать таблицу А
2. Оператор in не использует индексированное чтение и заведомо работает крайне медлено

Протестируем запрос на таблицах с 10000 записей (под рукой с большим не оказалось)

Результат:


Совсем немного переписав запрос:


Получим:


Добавлено через 2 минуты и 47 секунд
Zipper, скажи пожалуйста, а сколько времени требовалось серверу, что бы отдать тебе результат даже для 300000 записей? Насколько я понимаю минут 6 должен был бедняга трудиться.

Alex, что-то около 50 сек.

Так все таки блокировка существует?
Попробую твой вариант, сообщу о результатах. За ранее спасибо. Раньше работал с Oracle. Не достаточно еще разобрался с особенностями FireBird. Будем стараться.   

Официально известно одно ограничение массив элементов для оператора in не может превышать 1500 элементов 

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

Мне надо отобрать все записи id которых не встречается в другой таблице.
Я написал такой запрос

При выполнении выдается ошибка 
Arithmetic overflow or division by zero has ocurred.
arithmetic exception, numeric overflow, or string truncation.
Cannot transliterate character between character sets.

c.fields типа Blob, s.tab_num типа integer
В чем может быть дело?

Периписал запрос следующим образом

все заработало.
Наверно где-то в substring(c.fields from 9 for 6) были данные не конвертируемые в integer.

Это сообщение отредактировал(а) Zipper - 3.5.2007, 05:20

А еще одну проблему поможете решить?
Есть такой update

Надо дополнить поле fields таблицы cards, если оно пустое, строчкой '00000007'+табельный_номер, который берется из поля tab_num (типа integer) таблицы "1SOTRONOS" при совпадении фамилии имени отчества. Но дело в том что встречаются полные тезки и соответственно выбираются несколько записей табельного номера, а он уникальный. как мне исклбчить такую ситуацию? Пусть выбирался бы только один из них. Второго можно поправить руками.

в FB 2.0 и выше уже и in использует индексы

Добавлено @ 14:23

да это так, но в этом случае вываливается исключение, а не так что сервер тихо блокирует...

Добавлено @ 14:25
Zipper, это по идее уже должна была быть новая тема про UPDATE

Добавлено через 13 минут и 37 секунд
Alex, если можно использовать  exists, то вообще зачем тогда in? Или in это старый оператор, так сказать и его лучше не использовать?

Это сообщение отредактировал(а) Akella - 3.5.2007, 14:25

На практике это у него не всегда получается


лично мне до сих пор слабо верится, что там тихо промолчали...


Задачи разные у людей бывают

Вериться не вериться, а промолчал. 
То есть если SQL возвращает более 1500 тысячей записей в операторе IN ( select ...), то сервер такой запрос не выполнит и должен выдать исключение?

Лично я не уверен, что на select в in это условие распространяется


В чем тестировался запрос?