Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Быстрый поиск в ораклиной базе... [D6, Oracle]

Андрусь © (2002-10-21 21:43:00)
Привет всем! У меня такая проблема.Есть база, где большие таблицы(сотни тысяч). Нужно организовать быстрый поиск по конкретным полям в таблицах. Что-то вроде как в блокноте Ctrl+F - окошко, вводишь условия поиска... Когда все данные на клиенте всё очень просто - Locate().
В моём случае всё намного хуже. Сразу отметаем идею закачки всего на клиента и обработки там - долго грузится,да и громоздко всё качать. Нужно создавать для юзвера видимость работы с полным набором на клиенте, маскируя обработку на серевере.
Как вариант такое решение. В запрос включаю параметр,вокруг которого формирую набор данных. На событие Before Scroll на DataSet вешаю обработчик обновляющий набор данных,вокрух 1-й либо последней записи при достижении таковой. Неясно что делать со сколингом на гриде.Он будет показывать чушь.
Может кто занимался чем либо подобным буду очень благодарен за полезные советы и подсказки.

EternalWonderer (2002-10-30 17:16:00) [1]
Можно сократить объём переносимых на клиента данных не по вертикали, а по горизонтали (например, выводить только один столбец), и делать поиск по этому столбцу. А когда пользователь выбрал запись - тащить выбранную строку полностью.

Geka (2002-10-30 15:38:00) [2]
Использую DOA.
В TOracleDataSet есть свойство

property QueryAllRecords: Boolean;

Description

When set to True, all records will be retrieved from the database when the dataset is opened. When set to False, records are retrieved when a data-aware component or a program requests it. If a query can return many records, set this property to False if initial response time is important.

Вроде это то что надо.

А поиск можно и запросом с like сделать(будет точно как ctrl-f)

Diana (2002-10-30 14:07:00) [3]
Мне регулятно приходится работать с похожем объемом данных с точки зрения пользователя, и лучше настраиваемого фильтра, запускаемого на открытие окна я ничего не видела.
Искать просмотром нужную запись в таком объеме данных - нудно, а оценить количество записей можно, если вывести его в строку состояния.
Думаю стоит пересмортеть логику программы, а не зацикливаться на способах обмана ДБгрида. Это ни к чему.

ShuraGrp (2002-10-23 11:15:00) [4]
В ODAC TOraDataSet.FiltrSQL добавляет условие к Where

Sergey13 (2002-10-22 11:31:00) [5]
2Андрусь © (22.10.02 11:11)
>Таблица - порядко сотен тыс. записей.
Я спрашивал про набор данных возвращающегося селектом (без "ограничителей")
>Набор данных (-50,+50) ограничиваю селектом...
Каким образом? Текст запроса, плиз.
>Нечего прикалываться,если нет серьёзных мыслей.
Да я и не прикалываюсь. Просто, ИМХО, ты неправильно используешь поиск. Ты пытаешься искать в готовом наборе данных, а я думаю, что на таких объемах это неправильно. Надо разделить поиск и набор. Т.е. запрос поиска должен возвращать минимум строк(в идеале 1), с помощью результата поиска и перемещайся по набору(рабочему) данных. Но этот рабочий набор тоже не следует делать шибко большим - пользователь не сможет с ним нормально работать. Лучше сделать несколько маленьких. Как? Разумно ограничивать в запросе. Иногда даже можно специальные столбцы для этого иметь. Но это надо конкретно задачу смотреть.
В общем мой совет пересмотреть логику приложения.

Андрусь (2002-10-22 11:24:00) [6]
Там смотрю - очень интересно.
Есть ф-я TOCICommand.InternalFetch. Но фетч вперёд - видимо про таких извращенце вроде меня не думали. Можно написать наследника,
добавив фетч назад...

Андрусь (2002-10-22 11:11:00) [7]
>Sergey13 ©
Таблица - порядко сотен тыс. записей.
Набор данных (-50,+50) ограничиваю селектом...
Нечего прикалываться,если нет серьёзных мыслей.
>Johnny Smith ©
Работаю с Ораклом ч/з Odac. Он подсасывает OCI. Может проще работать через него. Ничего не посоветуете.

Sergey13 (2002-10-22 10:42:00) [8]
2Андрусь © (22.10.02 10:19)
>закачка полноо набора - слишком дорогое по времени
Сколько строк в наборе? Может тут и стоит рыть? Уменьшить попробовать.
>ограничиваю набор данных запросом+ограничение объёма данных - (-50,+50)
Каким образом?
>Этим пытаюсь создать у пользователя иллюзию работы
Вот это в точку, ИМХО. 8-)

Johnny Smith (2002-10-22 10:39:00) [9]
2Андрусь © (22.10.02 10:19)
Вот как раз фетчить через апишки,наверное,будет наиболее оптимально. Стоит позаморачиваться с ними,хотябы попробывать. Буду весьма признателен за подсказку.
Ну тогда ловите подсказку:
1) Примеры из директории %ORA_HOME%/OCI/Samples
Все примеры - на чистом С. Обратите внимание главным образом на примеры с простым селектом (особенно cdemo82.c). Там юзается функция OCIStmtFetch, у нее есть параметр orientation, который может принимать значения OCI_FETCH_NEXT или OCI_FETCH_PRIOR (последний - начиная с 8i). Вот этот orientation и будет помощничком.
2) Ну и документация:
http://download-west.oracle.com/otndoc/oracle9i/901_doc/appdev.901/a89857/toc.htm
В Ворде это страниц 800 текста :)) Я скачал. Не пожалел.

О том, как это портировать с С на дельфя, смотри исходники любой библиотеки прямого доступа (рекомендую NC OCI)

Андрусь (2002-10-22 10:19:00) [10]
>Sergey13 ©
Что конкретно неясно - набор данных закачиваю порциями, т.к.закачка полноо набора - слишком дорогое по времени. Для быстрого поиска ограничиваю набор данных запросом+ограничение объёма данных - (-50,+50)записей от перевой записи удовлетворяющей условиям поиска. Этим пытаюсь создать у пользователя иллюзию работы со всеми данными на своей машине.

>Johnny Smith ©
Вот как раз фетчить через апишки,наверное,будет наиболее оптимально. Стоит позаморачиваться с ними,хотябы попробывать. Буду весьма признателен за подсказку.

sen (2002-10-22 09:46:00) [11]
BIS
Зачем загонять в отдельный поток-то?
Подумай хорошенько.

Johnny Smith (2002-10-22 09:37:00) [12]
2Андрусь © (21.10.02 21:43)
Старая проблема.
Если говорить о возможностях OCI, то на их уровне такое возможно (двунаправленный курсор называется - при исполнении запроса можно фетчить строки как вперед так и назад), но вряд ли Вы будете с ними заморачиваться - APIшки они и в Африке APIшки.
Так что лучше все-таки фильтровать на сервере.

Bis (2002-10-22 09:29:00) [13]
У нас поиск реализован через пакеты.
Все функции возвращают ссылки на динамические или временные таблицы.
Чем точнее поиск, тем быстрее вернет результаты. А когда много, то результат лучше фечить. И лучше загнать это в отдельный поток, который понемногу скачивает данные и отображает их

Sergey13 (2002-10-22 09:02:00) [14]
Ничего не понял. Тебе надо закачивать набор данных порциями? Так обычно компоненты доступа так и делают автоматом. Для быстрого поиска ограничивай сам набор данных более конкретным запросом. Вытаскивать больше 100 строк не резонно, не удобно работать.

>На событие Before Scroll на DataSet вешаю обработчик обновляющий набор данных
И получишь на одном и том же наборе затык полный. 8-)

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »