Dbexpress. Стоит ли?

← →
DJohn (2003-12-05 14:27) [0]

Стою перед проблемой: Какие компоненты выбрать для доступа к Informix. Dbexpress или InformixDataAccess(Luxena)?
Компоненты IDA похожи на IBX, FIBC с которыми я работал раньше
С dbexpress никогда не работал, но думаю технология перспективная и стоит заняться ее изучением, тем более что при замене сервера БД, изменения в коде будут минимальны. Как в dbexpress на счет глюков, багов и много ли времени занимает освоение? Полезна будет любая информация.

← →
Sandman25 (2003-12-05 15:43) [1]

IDAC стоит деньги, DBExpress бесплатен. Но есть и проблемы - в D7 TSimpleDataset не понимает секцию where. В D6 TSQLClientDataset запрашивает информацию о полях, даже если все указано явно. При замене на связку TSQLDataSet-TPorvider-TClientDataset и явной настройке полей скорость взлетает до бесконечности, нет никаких обращений к системным таблицам. Надо установить NoMetadata в true. Я такой скорости даже при работе с локальной БД типа Paradox не видел. Но при использовании TSQLProc происходит обращение к системным таблицам для проверки правильности параметров, при замене на TSQLDataset с CommandText = "execute procedure ..." и настройке параметров скорость выполнения опять таки взлетает до небес.
Освоение очень быстрое, компоненты просты. Работа с Blobами имеет свои особенности, но тоже ничего сложного.

← →
Sandman25 (2003-12-05 16:03) [2]

Хочу добавить, что все выражения для компонент я беру из ini файла, поэтому для переноса приложения на другую СУБД достаточно будет в этом файле изменить SQL выражения. Например, вместо select ... outer (table) написать select .. left outer join. Вместо create temp table .. with no log написать соответсвующее выражение для данной СУБД и т.д.

← →
DJohn (2003-12-06 15:29) [3]

Sandman25 благодарю за ответ, с выбором определился.

← →
Fast (2003-12-07 14:58) [4]

см. книгу Эрик Хармон "Руководство разработчика баз данных в Delphi/Kylix". Изд "Вильямс" СПб, 2002

← →
kdy (2003-12-11 09:30) [5]

Попробовал посмотреть в гриде результат простого запроса (~ 22 000 записей).
BDE ( DataBase + Query) ~ 0,05 c
BDE ( DataBase + Query + ClientDataSet ) ~ 17 c
dbExpress ( SQLConnection + SQLClientDataSet )~ 15 c
Если я не собираюсь редактировать свою базу прямо в гриде, что хорошего мне даст переход на dbExpress?

← →
kdy (2003-12-11 09:55) [6]

dbExpress ( SQLConnection + SQLQuery )~ 0,04 c
Но к сожалению результат SQLQuery нельзя сразу посмотреть в гриде. Если хочешь посмотреть - надо результат запроса закачивать в ClientDataSet, а именно тут будут самые большие тормоза (~ 15 c).

← →
Sandman25 (2003-12-11 10:32) [7]

[6] kdy (11.12.03 09:55)

Сколько записей закачивается в ClientDataSet, если они закачиваются 15c? Может, стоит добавить к запросу секцию where? :)

PS. По Вашим же данным получается, что dbExpress работает быстрее BDE.

← →
Sandman25 (2003-12-11 10:38) [8]

kdy

Прочитайте мой первый пост в этой ветке. TSQLClientDataSet использовать не стоит.

← →
kdy (2003-12-11 12:34) [9]

[7] Sandman25 © (11.12.03 10:32)
[8] Sandman25 © (11.12.03 10:38)

Действительно, сами по себе close+open в dbExpress работают немного быстрее. Но если с полученным из BDE набором данных сразу можно работать , то данные dbExpress придётся (в большинстве случаев) закачать ещё и в клиентский набор. Со всеми вытекающими тормозами. И не важно, будет ли зто
TSQLClientDataset или TSQLDataSet-TProvider-TClientDataset - я пробовал оба варианта и скорость у них примерно одинаковая.
Насчёт where - как правило я так и делаю, но иногда приходится иметь дело с большими объёмами, и 22000 записей далеко не предел.

← →
Sandman25 (2003-12-11 12:43) [10]

[9] kdy (11.12.03 12:34)

А Вы не пробовали при работе с BDE закачивать те же самые 22 тысячи записей сразу?
Query.FetchAll. Те же самые 15 сек, если не больше.

И все-таки зачем закачивать 22 тысячи записей? Спорим, что найдется способ, при котором это не понадобится?

← →
kdy (2003-12-11 13:09) [11]

>А Вы не пробовали при работе с BDE закачивать те же самые 22 тысячи записей сразу?

[5] kdy (11.12.03 09:30)
BDE ( DataBase + Query) query.close/query.open ~ 0,05 c

Причём всё это сразу видеть в гриде, работает поиск, фильтр. И быстро.
Дело не в количестве записей, дело в принципе. Для пользователя важна скорость работы. И если 22000 - довольно редкий случай, то 2000..5000 - обычное дело (это уже с where). Пусть это будут тормоза не 15, а 2..5 секунд. Всё равно долго по сравнению с 0,05 с для БДЕ.

> Спорим, что найдется способ, при котором это не понадобится?
Например?
Не всегда можно ввести дополнительные фильтры. Иногда нужен поиск в большом наборе данных.

← →
MV (2003-12-11 13:21) [12]

Ну, типа, эта...
А вы никогда не задумывались о том, что уже давно скорость достаупа слабо зависит от используемых компонент (за исключением всяких TTable, которые, как их ни ругают, неплохо оптимизированы /кэширование всякое там/), а в основном от сервера, архитектуры приложения и используемых приемо (запросы, индексы, планы, кэши и т.п.)?

← →
Sandman25 (2003-12-11 13:25) [13]

[11] kdy (11.12.03 13:09)

ClientDataSet при работе с BDE загружает только те данные, которые видны в DBGrid. Попробуйте настроить CLientDataSet так, чтобы он делал то же самое при работе с TSqlDataset.

В любом случае, даже 2000 записей не должны быть обычным делом. Не говоря уже о 5000. У меня пользователь всегда вводит фильтр, который позволяет ограничить число записей до 1. Если пользователь ввел такой фильтр, что ждет 15 секунд, то это его личные проблемы.

>Например?

Я недавно об этом писал. Используется два грида. Для одного пользователь указывает фильтр, и отображаемые записи может обрабатывать (кнопками) либо перетаскивать в нижний грид. А нижний грид - это либо ClientDataSet.CreateDataset, либо запрос из временной таблицы, в зависимости от СУБД и конкретной задачи. Затем можно запустить операцию, которая работает со всеми данными нижнего грида.
Например, нужно выбрать передать в хранимую процедуру все записи, которые
1) начинаются на A
2) заканчиваются на B
3) имеют внутри С.

1)Ставится фильтр A%, жмется кнопка для переноса данный в нижний "грид".
2)Ставится фильтр %B, жмется кнопка.
3)Ставится %C%, жмется кнопка.

Если же наоборот, нужно сделать операцию со всеми данными, кроме этих, то можно предусмотреть CheckBox(RadioGroup) и при необходимости использовать Not Exists.

PS. Если даже фильтр A% дает больше 2000 записей, то нужно переделывать хранимую, и передавать не записи, а маску "A%".

← →
kdy (2003-12-11 15:34) [14]

> ClientDataSet при работе с BDE загружает только те данные, которые видны в DBGrid
По моему, так делает Query, а ClientDataSet хапает сразу всё, откуда и тормоза при загрузке.

> Попробуйте настроить CLientDataSet так, чтобы он делал то же самое при работе с TSqlDataset.
Это как?

> В любом случае, даже 2000 записей не должны быть обычным делом.
Таковы требования. Нужно отображать все данные за месяц, а там уже пользователь может ввести дополнительные фильтры.

> Я недавно об этом писал.
А поподробнее где можно почитать?

И опять-таки вопрос: где можно увидеть реальное, значительное превосходство dbExpress в скорости?

← →
Sandman25 (2003-12-11 15:53) [15]

>По моему, так делает Query, а ClientDataSet хапает сразу всё, откуда и тормоза при загрузке.

Нет. Посмотрите TCustomClientDataSet.PacketRecords

>Это как?

Знаю, что это возможно, но не знаю, как именно. Мне никогда это не нужно было.

>Нужно отображать все данные за месяц, а там уже пользователь может ввести дополнительные фильтры.

Почему именно за месяц?. Сделайте 2 поля (дата начала-дата конца) и добавьте их к остальным фильтрам (название и так далее).

>А поподробнее где можно почитать?

Искать на форуме. Но я главную мысль Вам расписал - разделять большие операции выбора на несколько маленьких.

>И опять-таки вопрос: где можно увидеть реальное, значительное превосходство dbExpress в скорости?

В том то и дело, что при правильном написании программы разницы почти не будет - 0.04 против 0.05. Как в BDE, так и в dbExpress на передачу данных через соответсвующий слой (BDE и dbExpress) тратятся очень малые доли секунды.

Dbexpress. Стоит ли? Найти похожие ветки