![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
SQL запрос на поиск ну очень большого числа значений.
Arsenija © (2007-04-02 17:55:00)Имеется таблица test, в которой имеется два столбца (Фамилия и идентификационный номер-ID (уникальное поле). Имеем список искомых ID.
Формируем запрос:
select * from test.dbf where ID IN ("01100300098456","01590506704404","01590506693664","01100300098621","0110030036 2928","01100300127032".................)
Вопрос: если список искомых значений большой (более 10 тыс.), то как сформировать запрос?
Sergey13 (2007-04-03 11:21:00) [21]> [19] Arsenija © (03.04.07 11:18)
> Как это не смешно, но именно та
Если вы пойдете таким путем вы напишете не менее (в лучшем случае) кривой софт, чем то что работает сейчас.
Это делается проще. Создается (если его нет) уникальный индекс по ID. Вставляете по одной записи (если не заморачиваться на временной хранилище новых записей) и отлавливаете исключение о нарушении уникальности (просто пропускаете неудачные записи).
Arsenija (2007-04-03 11:18:00) [22]Sergey13
>Юзер визуально должен выявить дубликаты ИД?
Как это не смешно, но именно так.
Arsenija (2007-04-03 11:16:00) [23]Sergey13
В будущем наверное заменим кривой буржуйский софт своим, но пока добавление в базу проиходит именно как в посте [17].
Arsenija (2007-04-03 11:13:00) [24]StriderMan © (03.04.07 11:02) [13]
> Если ID не уникален будет полный безондерс
> а не проще ли средствами БД отслеживать уникальность поля? кажется в
> любой СУБД есть такая возможность.
> а что будете делать если такой ID уже есть?
У нас база. Мы в принципе знаем ее структуру. Есть кривой софт для работой с базой (добавление записей (файлы по 10 тыс), удаление из базы записей, редактирование служебных полей каждой записи). Кривизна софта заключается в том, что при добавдении он особо не заморачивается на предмет дублирования. Начинает добавлять, если запись в базе с таким ID уже существует, то прога выдает ошибку и самозакрывается. Что мы делаем тогда: ищем запись - удаляем - начинаем заново добавлять 10тыс записей. Таким образом теоретически возможно 10тыс таких процедур. Времени тратится море, тупизна полная. Хотим написать прогу проверки дублей сразу всех.
StriderMan (2007-04-03 11:11:00) [25]
> Desdechado © (03.04.07 11:07) [15]
> Это гда ты такое вычитал? 32 килобайта.
VARCHAR(255) максимум. по крайней мере в FB 1.5 точно так.
Desdechado (2007-04-03 11:07:00) [26]> Если IB/FB то строки там 255 символов, не больше.
Это гда ты такое вычитал? 32 килобайта.
Sergey13 (2007-04-03 11:04:00) [27]> [11] Arsenija © (03.04.07 10:53)
> интересуют 10 тыс значений из файла (всего в файле 10тыс)
> , так как их потом будем добавлять в базу. Если ID не уникален
> будет полный безондерс.
И зачем тогла в грид выводить? Юзер визуально должен выявить дубликаты ИД? Не смешите мои тапочки. Читайте из файла и пишите в базу с отловом исключения или с предпроверкой наличия дубликата (это хуже на таких объемах).
StriderMan (2007-04-03 11:02:00) [28]
> Если ID не уникален будет полный безондерс
а не проще ли средствами БД отслеживать уникальность поля? кажется в любой СУБД есть такая возможность.
а что будете делать если такой ID уже есть?
StriderMan (2007-04-03 10:59:00) [29]
> Если можно поподробнее про временную таблицу, как ее создать
> или ссылку на ресурс, где это описано. Буду премного благодарен.
от FoxPro только название знаю, в руках не держал. Но суть проста: временная таблица - это такая же таблица как и все остальные, и создать ее можно точно так же как и любую другую
например что-то типаCREATE TABLE TMP_ID(ID INTEGER).
Если описаная задача будет выполняться регулярно, то имеет смысл эту таблицу не убивать после использования. А может быть и данные в ней стоит сохранять
Arsenija (2007-04-03 10:53:00) [30]ЮЮ
интересуют 10 тыс значений из файла (всего в файле 10тыс), так как их потом будем добавлять в базу. Если ID не уникален будет полный безондерс.
Arsenija (2007-04-03 10:50:00) [31]Sergey13
"То-то пользователь наверное обрадуется. 10000 записей - просто посмотреть и то с утра до обеда листать будет. 8-)" - вероятность что записи будут найдены достаточно минимальна. Другими словами 10тыс записей проверяются на предмет повтора (уникальности) перед ихи добавлением в таблицу. поэтому как правило поиск дает либо мало записей либо совсем ничего.
"Может что в подходах к юзерскому интерфейсу поменять?" - не понял мысль, поясни пожалуйста.
StriderMan
СУБД - FoxPro. Насчет временной таблицы - похоже это выход, я в принцыпе и заткнулся на длине (символьной и размерах искомого множества) SQL запроса. Если можно поподробнее про временную таблицу, как ее создать или ссылку на ресурс, где это описано. Буду премного благодарен.
ЮЮ (2007-04-03 10:40:00) [32]>Полученный список просто выведу в DBGrid. 10тыс
А чего так себя, любимого, так ограничивать - 100 млн. в гриде гораздо впечатлительней :)
>>кстати, а изначально откуда ID-шники берутся? не юзер же > более 10 тыс вводит?
>список искомых ID берется из файла
А файл откуда берется? Почему интересуют именно эти 10 тыс? Зачем все сразу? Почему не ограничиьтся поиском действительно нужных(естественно, небольшого числв) из 100 млн?
StriderMan (2007-04-03 10:38:00) [33]
> Arsenija © (03.04.07 10:30) [5]
> Полученный список просто выведу в DBGrid.
поэтому с
> в цикле по очереди. 10000 итераций цикла - не так уж и много
не получится. как один датасет в итоге получить? MemDataSet использовать? вообще не выход.
Короче я за временную таблицу.
Можно конечно вывернуться, написать ХП, парметром в нее строку бесконечной длины. Кстати СУБД какая? Если IB/FB то строки там 255 символов, не больше. придется БЛОБ-ом передавать, и в ХП его парсить.
Короче временная таблица на мой взгляд самое оно.
Sergey13 (2007-04-03 10:37:00) [34]> [5] Arsenija © (03.04.07 10:30)
> Полученный список просто выведу в DBGrid.
То-то пользователь наверное обрадуется. 10000 записей - просто посмотреть и то с утра до обеда листать будет. 8-)
Может что в подходах к юзерскому интерфейсу поменять?
Arsenija (2007-04-03 10:31:00) [35]к тому же она юзается постоянно не только мной, поэтому время поиска хотелось бы уменьшить до минимума.
Arsenija (2007-04-03 10:30:00) [36]Полученный список просто выведу в DBGrid. 10тыс итераций цикла не много, но база в которой ищется велика (примерно на 10-100 млн записей)
Sergey13 (2007-04-03 10:06:00) [37]> [0] Arsenija © (02.04.07 17:55)
А что ты дальше будешь с полученным списком найденных делать? Почему нельзя искать в цикле по очереди. 10000 итераций цикла - не так уж и много.
Arsenija (2007-04-03 09:52:00) [38]список искомых ID берется из файла
StriderMan (2007-04-02 18:55:00) [39]кстати, а изначально откуда ID-шники берутся? не юзер же > более 10 тысвводит?
StriderMan (2007-04-02 18:40:00) [40]воспользуйся временной таблицей. закачай туда ID-шники.
далееSELECT T.* FROM TEST.DBF T JOIN TMP_ID.DBF I ON I.ID = T.ID
Иначе зло.