Компоненты для работы с БД PostgreSQL.

← →
Fredericco © (2004-09-27 19:44) [0]

Возникла необходимость работать с сабжевой БД.
Был выбран компонент от фирмы MicroOLAB.

Исходные данные:
Записей в таблице - 21400
Физически таблица занимает места - 10 мегабайт
Сами данные от сервака на клиентскую машину, после sql запроса, идут - 3-4 секунды (что, для нас, удовлетворительно)

Недостаток:
Когда таким количеством записей наполнен DataSet, то перебор всех записей у DataSet"а методами Next или MoveBy, становиться до неприличия долгим.
Простой код:
First; While EOF do Next;
выполняется за 5-6 минут!
В связи с этим вопросы:
1) Может кто уже работал с этими компонентами, и сталкивался с этой проблемой?
2) Нет ли других компонентов для работы с сабжевой БД?

Заранее благодарен,
с уважением Fredericco.

← →
Fredericco © (2004-09-28 10:05) [1]

Сорри очепятка, есессно:
First; While not EOF do Next;

← →
Nikolay M. © (2004-09-28 10:13) [2]

> 2) Нет ли других компонентов для работы с сабжевой БД?

Zeos Library. Сам не работал.

← →
Fredericco © (2004-09-28 10:23) [3]

2 Nikolay M. © (28.09.04 10:13) [2]
Уже пробывал.
Чего то не работают.
Скорей всего они не совместимы с нашей версией сервака (7.4)

← →
Плохиш © (2004-09-28 10:32) [4]

Чем АДО не нравится?

← →
Плохиш © (2004-09-28 10:36) [5]

http://gborg.postgresql.org/project/psqlodbc/projdisplay.php

Ответ на следующий (ещё не заданный) вопрос ;-)

← →
Anatoly Podgoretsky © (2004-09-28 10:44) [6]

PostgreSQL говоришь, а чего же работаешь навигационными методами, а не реляционными. Все должно летать.

← →
Fredericco © (2004-09-28 10:51) [7]

2 Anatoly Podgoretsky © (28.09.04 10:44) [6]
Это не я так работаю :-)
Я лишь член небольшой команды.
И тут лишь в планах работать реляционными. Пока основной упор делается на работу с большим числом различных БД.

← →
Денис (2004-09-28 10:53) [8]

Вы для начала с Paradox разберитесь (First, Next :-)

← →
Fredericco © (2004-09-28 11:00) [9]

2 Плохиш © (28.09.04 10:32) [4]
Спасибо за ссылку, но я его уже пробывал и либо лыжи, либо я:

BDE Error: 12550
Invalid configuration parameter.
Alias: ODBC1

Скорей всего я, да? :-)

← →
Плохиш © (2004-09-28 11:11) [10]

> Fredericco © (28.09.04 11:00) [9]

> BDE Error: 12550

с BDE не работаю, не знаю. АДО работает без проблем.

> Скорей всего я, да? :-)

это не я сказал ;-)

← →
Плохиш © (2004-09-28 11:16) [11]

> Fredericco © (28.09.04 11:00) [9]

Только что попробовал БДЕ, все работает!
Настой правилино ODBC-драйвер.

← →
Плохиш © (2004-09-28 11:17) [12]

> Плохиш © (28.09.04 11:16) [11]

Фи :-)
правилино = правильно
Настрой DNS

← →
pasha_golub © (2004-09-28 11:23) [13]

Рассказываю прикол.
PostgreSQLDAC. DAC - Direct Access Component
И на кой этот гемор с БДЕ, ОДБС, АДО и т.д.

Далее, тебе Подгорецкий умную вещь сказал!!! На хера бегать по всему датасету из начала в конец?

Ты когда нибудь видел чтобы оператор напрямую работал с 21000 записей? Это в страшном сне такого не увидишь! Если видел, то привели плиз ситуацию.

← →
Плохиш © (2004-09-28 11:35) [14]

> pasha_golub © (28.09.04 11:23) [13]

Вы про это http://microolap.com/dac/pgsql/index.htm ?
Больше всего понравились два пункта "PostgresDAC is a royalty-free product" и "Try a fully functional trial version" :-)
учитывая, что psqlODBC распостраняется под LGPL.

← →
pasha_golub © (2004-09-28 11:40) [15]

Плохиш © (28.09.04 11:35) [14]
Да, я про это.

А что смущает? Версия действительно полнофункциональная, единственное отличий зарегистрированной - это наличие тех. поддержки и отсутствие модального окошка с напоминанием при коннекте к БД. Все.

← →
Плохиш © (2004-09-28 12:03) [16]

> pasha_golub © (28.09.04 11:40) [15]
> Версия действительно полнофункциональная,
> единственное отличий зарегистрированной - это наличие тех.
> поддержки и отсутствие модального окошка с напоминанием
> при коннекте к БД.

Дальше продолжать нет смысла. Хотя попробуем :-) Zeos тест не прошёл :-) Посмотрим, чего накрутили здесь

← →
pasha_golub © (2004-09-28 12:12) [17]

Плохиш © (28.09.04 12:03) [16]
А что за тест? У меня? например? Зеос неправильно возвращал сложные запросы типа:

(SELECT ...)
UNION
(SELRCT ...)

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

← →
Fredericco © (2004-09-28 12:13) [18]

Плохиш ©
Сенкс, но через АДО получается 30-40 секунд. Причем это время уходит на скачивание записей с сервера. Как только загрузка завершена то данные готовы.
Правда 30 секунд все равно много :-((

← →
sniknik © (2004-09-28 12:26) [19]

> Сенкс, но через АДО получается 30-40 секунд.
30-40 сек много? вместо 5-6мин?

т.к. то что похоже у тебя было
> Сами данные от сервака на клиентскую машину, после sql запроса, идут - 3-4 секунды (что, для нас, удовлетворительно)
похоже это просто открытие серверного курсора
и
> First;
> While not EOF do Next;
> выполняется за 5-6 минут!
а это fetchall, скачка на клиента по мере обращения.
что теперь с ADO на похожем цикле? должно "пролетать" мгновенно.

> Правда 30 секунд все равно много :-((
смени клиентский курсор на серверный, поведение будет аналогично описанному в [0]
ускорить открытие клиентского можно асинхронным выполнением (откроется с неполными данными, до конца докачается в фоне)

← →
Fredericco © (2004-09-28 12:50) [20]

sniknik © (28.09.04 12:26) [19]
Все равно много :-)
Просто достаточно большой проект. Со своими ошибками на этапе разработки. Я не руководитель :-). Ошибка в следующем. Тут все данные имеющиеся в базе отображаются сразу. То есть в программе не предусмотренно никаких фильтров. Хуже того, таблицы по lookup полям тоже сразу забираються после начитывания родительской. Полностью. Ну вот так вот тут - неправильно. Переделыать будем. Но потом.
К примеру в IB таблица в 30000 записей отображается за 3-4 сек. Полностью.

← →
Johnmen © (2004-09-28 12:59) [21]

>Fredericco © (28.09.04 12:50) [20]
>в IB таблица в 30000 записей отображается за 3-4 сек. Полностью.

На экране ?
:))))))

← →
Fredericco © (2004-09-28 13:02) [22]

2 Johnmen © (28.09.04 12:59) [21]
Да. Зрелище не очень.

> sniknik © (28.09.04 12:26) [19]
> Все равно много :-)
при серверном курсоре будут те же 3-4 сек (в основном при первом подключении, на само время подключения)
при ассинхронном запросе открытие и показ первой порции будет мгновенным (не считая того же времени подключения если его не было), и это много? а сколько в самый раз, минус пол часа?

> 2 Johnmen © (28.09.04 12:59) [21]
> Да. Зрелище не очень.
ну так в чем проблема? такое количество одновременно отображонных записей (30тыс) на экране, это слошной серый фон... вставьте такую картинку на открытие и не морочте всем мозги.

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

sniknik © (28.09.04 13:33) [23]

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

Я бы тоже с удовольствием почитал. Можно ссылочку?

> Fredericco © (28.09.04 12:13) [18]

Ну sniknik уже всё объяснил :-))

> pasha_golub © (28.09.04 12:12) [17]

Тест на скорость. Имеется работающая программа с использованием ADO, переделывается на другой движок и сравнивается время. Результаты для PostgresDAC не утешительные. В 4 раза медленней чем ADO.

2 sniknik © (28.09.04 13:33) [23]
//по моему тебе нужно заполнить пробелы в образовании, по теме ..клиентские/серверные курсоры, и что именно отображается в гридахdbконтролах, а что нет.
тогда все станент на свои места.

Не спорю. :-)

Но вот какая задача стоит передо мной.
Трое человек, в том числе и я, пишут компонент-переходник между нашей программой и разными типами БД. Я создаю класс, наследуясь от одного нашего стандартного. Среди прочих методов, которые мне надо перекрыть( что б мой компонент, собственно, работал нормально со все программой), есть два: Open, RecordCount и LoadRecord(RecNum:integer; aRecord:TObject). Есессно там есть и многие другие, но это не важно.
Когда в программе хотят отобразить таблицу, вызывают Open, а потом последовательно LoadRecord для всех записей. Так вот, после Open я данные из таблицы должен уже иметь. Что бы на каждый LoadRecord выдавать запись из моего набора данных (TDataSet, наследник от TDataSet, какого угодно хоть TList, главное что б данные уже были у меня). Где потом эти данные отображаются мне все равно. А отображаются они в самых различных местах. И впринципе без разницы где будет задержка выборки данных: на этапе Open или на каждом вызове LoadRecord - главное что б ее не было.
Да и кстати, мои познания в программировании не ограничиваются киданием мышкой компонентов на форму и прописыванием свойств в ObjectInspector"е. :-)

Плохиш © (28.09.04 14:22) [25]
Тест тесту рознь. Зато при большщом кол-ве записей АДО выдаст "Out of memory". Был уже прецендент, а ДАС не выдаст.

ДАС проигрывает по скорости тестам по навигации, сродни коду в [0]. А в остальном не думаю.

Fredericco © (28.09.04 14:30) [26]
Да и кстати, мои познания в программировании не ограничиваются киданием мышкой компонентов на форму и прописыванием свойств в ObjectInspector"е. :-)

Забыл добавить про поиск файлов FindFirst\FindNext. :-D

> Fredericco © (28.09.04 14:30) [26]

Так и ищи данные только когда их у тебя попросят.

> главное что б ее не было

Все процессы в мире протекают с конечной скоростью.

> Я бы тоже с удовольствием почитал. Можно ссылочку?
выбирай любую
http://www.yandex.ru/yandsearch?stype=www&nl=0&text=%C5%EB%EC%E0%ED%EE%E2%E0

у меня вот такая
http://books.dore.ru/bs/f1bid405.html
(сразу попалась)
и такая
http://books.dore.ru/bs/f1bid1156.html
http://www.yandex.ru/yandsearch?text=%CC%E0%E9%EA%EB+%CE%F3%F2%E5%E9&stype=www
и еще 3 или 4 дома (не помню авторов поэтому найти проблемно)
покупалось в основном ради кусочка инфы... того чего почемуто не оказывалось в других книгах, елманову к примеру купил ради RDS которое там так полностью и не раскрывается ;( как оказалось, а начинал учить (ADO) по хелпам, книг вначале не было ;о( да и в инете статьи не находились (первую нашол на королевстве, поздно, в основном все уже сам пробовал).

> пишут компонент-переходник между нашей программой и разными типами БД. ...
ADO решили заменить? ;о))
делать ничего не надо, перекрой ADODataSet (не закрывая имеющиеся сейчас свойства), будеш иметь все что описал + еще много много всего.

> pasha_golub © (28.09.04 14:35) [27]
> Плохиш © (28.09.04 14:22) [25]
> Тест тесту рознь.

Никто и не спорит.

>Зато при большщом кол-ве записей АДО выдаст
> "Out of memory

Цифру большого количества в студию.

> Зато при большщом кол-ве записей АДО выдаст "Out of memory". Был уже прецендент, а ДАС не выдаст.
ADO со стандартными настройками (как компонент с палитры ложиш) работает с локальным курсором (весь датасет перекачивается на клиента сразу), дак видать настроен на серверный, раз памяти меньше "ест", ничего не стоит и ADO на то же настроить.
потом, в старых версиях была проблема с памятью (встречался), помогает установка новой (все проблемы с этим решились после включения последнего MDAC-а в инсталяшку (6-й на тот момент)).

Плохиш © (28.09.04 14:39) [30]
Не скажу. Информация получена от разработчика лично. Я лично с этим прецентдентом не сталкивался.

sniknik © (28.09.04 14:46) [31]
ДАС работает через клиентскую ДЛЛку pglib.dll, а та в свою очередь сама разбирается с данными. И что к чему у этой библиотеки знает только разработчик видимо.

Компоненты для работы с БД PostgreSQL. Найти похожие ветки