Paradox VS Interbase

← →
Alexei Sviridov (2003-05-14 14:44) [0]

Imeetsja baza na Paradox 115 000 records.Pojavilas nadobnost" perevesti ento delo na interbase. I chto zhe poluchaetsja, chto interbase rabotaet medlennee chem paradox. Pravilno li eto? Naprimer, posle otkritija tablici dlja perehoda k poslednej zapisi Interbasu nuzno primerno 9 secund, v to vremja kak v paradox"e eto proishodit mgnovenno. Takzhe raznica v skorosti ochen zametna pri ispolzovanii metoda LOCATE. Dostup k Interbase u menja cherez IBTAble. Server registered local. Spasibo

← →
Johnmen © (2003-05-14 15:04) [1]

>Pravilno li eto?

В корне нет !
Рекомендую перед любыми телодвижениями в сторону IB (да и любого SQL сервера) внимательно изучить соответствующую литературу по нему для понимания идеологии и приемов работы...:)

← →
snake1977 (2003-05-14 15:44) [2]

во первых!!! есди ты использеш IB то надо пользоваться исключительно TQuery, а не TTable и никаких LOCATE!!!
во вторых!!! и это связано с первым, сделай индексы по полям , по которым стит where условие в выборке !! , какие индексы завести , можно узнать из просмтора плана выполнения запроса :)

← →
Alexei Sviridov (2003-05-14 15:53) [3]

To Johnmen
Ne posovetuete ssilochku na doc"u

← →
Соловьев © (2003-05-14 15:54) [4]

> Alexei Sviridov (14.05.03 15:53)

www.ibase.ru

← →
Alexei Sviridov (2003-05-14 15:58) [5]

to snake1977
>во первых!!! есди ты использеш IB то надо пользоваться >исключительно TQuery, а не TTable
Ja ispolzoval TIBTable...
> и никаких LOCATE!!! a chto vzamen dlja bistrogo perehoda?
Dlja perehoa k poslednej zapisi zanimaet mnogo vremeni esli ja dazhe otkrivaju tablicu v IBConcole - tak chto zhe eto?

← →
гончий (2003-05-14 16:04) [6]

Не вижу существенных отличий TIBQuery от TIBTable, один является наследником другого и по сути является тем-же Query, только для удобства обзаведенный свойством TableName

← →
[NIKEL] © (2003-05-14 16:24) [7]

TIBQuery от TIBTable -> ими вообще пользоваться нерекомендуется...

а сравнивать Paradox и Interbase...
все равно, что сравнивать, что красивее, сапоги или диван?

← →
sts (2003-05-14 19:33) [8]

Еще, по моему, есть разница в способе доступа к данным - IBX или BDE.
IBX (как и FIB) рассчитан на работу с запросами к таблицам, а не с таблицами целиком - т.е. при Last он честно выфетчивает все записи.
другой подход состоит в том, что можно выфетчивать не сначала, а с конца, не вытягивая при этом промежуточные записи (я все про last говорю).
Есть компоненты которые работают именно так (см. на ibase.ru).
Слышал, что нечто похожее используется в BDE - впрочем, сам я этого не проверял, но где-то мелькало такое утверждение.
Исходя из последнего предположения в BDE переход к последней записи должен выполняться быстрее.

← →
Dred2k © (2003-05-14 19:38) [9]

> Еще, по моему, есть разница в способе доступа к данным -
> IBX или BDE.

Еще допущу предположение, что есть разница между работой серверов локально и не локально, под Win98 и нт платформами (плюс еще разные варианты, смотря от качества конфигураций и т.п.). Минимальная доказательная база - личные наблюдения. ;)

← →
Zacho © (2003-05-14 19:49) [10]

> sts (14.05.03 19:33)
> другой подход состоит в том, что можно выфетчивать не сначала,
> а с конца, не вытягивая при этом промежуточные записи (я
> все про last говорю).
> Есть компоненты которые работают именно так (см. на ibase.ru).

Нельзя.И нет таких компонент. Либо ты говоришь про что-то другое.

← →
awex (2003-05-15 11:46) [11]

"gb_DataSets Components" - является набором компонентов, обеспечивающим возможность НОРМАЛЬНОЙ навигации на больших источниках данных - таблицах и запросах. Набор состоит из двух компонентов: TgbDataSet и TgbTable. Первый из них обеспечивает кэширование, навигацию, редактирование на произвольном наборе
данных, который возвратил SQL-запрос, второй, аналогичную функциональность на отдельно взятой таблице. В отличие от стандартных IBX- и FIBPlus- DataSet-ов, gb_DataSet-ы НИКОГДА не скачивают всего объема данных с InterBase-сервера. То
есть основное (и принципиальное) различие с такими компонентами как IBTable, IBDataSet, IBQuery, pFIBDataSet, состоит в архитектуре кэша, и методике обращений к серверу.

← →
awex (2003-05-15 11:51) [12]

Это вырезка из readme "gb_DataSets Components",
все остальные подробности в этом же файле.

Если использовать этот компонент, то Interbase в плане
навигации по данным будет смотреться "лучше".. :)))

← →
Danilka © (2003-05-15 12:14) [13]

Вообще, если честно, не могу представить такую задачу, когда юзеру надо видеть ВСЕ 115 000 записей.
Как правило ему надо 1-20 по каким-то условиям. из любого набора, хоть мильен записей. :))
Если хорошенько подумать в этом направлении, уверен, можно организовать интерфейс таким образом, что и сеть не будет грузиться выкачивая все записи, и юзеры довольны - все быстро и удобно. :))
И, по-моему, на серваке это сделать проще/удобнее, чем на парадоксе. Кстати, наверное, по этому в IBX и FIBPlus не реализовано то, что есть в gb_DataSets - можно все делать так, что эта функциональность не понадобится.

← →
Alexei Sviridov (2003-05-15 12:30) [14]

> Danilka © (15.05.03 12:14)
> Вообще, если честно, не могу представить такую задачу, когда
> юзеру надо видеть ВСЕ 115 000 записей.

Vse ochen prosto, eto baza productov na skalade, a nado videt vse zapisi dlja bistrogo peremeschenija po baze. V Paradox"e ja otkrival table i ispolzoval metod locate...

← →
Alexei Sviridov (2003-05-15 12:33) [15]

> awex (15.05.03 11:51)
> Это вырезка из readme "gb_DataSets Components",
> все остальные подробности в этом же файле.
>
> Если использовать этот компонент, то Interbase в плане
> навигации по данным будет смотреться "лучше".. :)))

Ne podskazhite gde ego vzjat?

← →
Danilka © (2003-05-15 12:47) [16]

Alexei Sviridov (15.05.03 12:30)
очень не согласен. и не пойму, что значит "быстрое перемещение по базе".
все склады которые я видел организованы совсем по-другому, наоборот, не видел ни одного склада, когда все записи по всем продуктам сразу показывались.
есть группы товаров, есть различные фильтры наконец, да мало-ли чего, вот в 1с-ке, например, слева дерево групп, спросите у тех юзеров, кто с таким деревом работает - говорят так им очень удобно.

а gb_DataSets можно взять на torry.net

← →
Zacho © (2003-05-15 12:47) [17]

> awex (15.05.03 11:46)

Я ,может быть, и ошибаюсь, но насколько знаю, в IB просто невозможно получить "последние" записи резалтсета без выборки всех предидущих, т.к. даже сам сервер "не знает", сколько записей выбрано запросом. Если кто-нибудь это опровергнет - даже буду рад. Только, пожалуйста, не общими фразами, а конкретными ссылками.
P.S. Об этих компонентах первый раз слышу, хотя стараюсь быть в курсе всего, связанного с IB.

← →
Danilka © (2003-05-15 12:52) [18]

видел, например, быстрый поиск по наименованию, пользователь пишет название продукта, начало, например: "колба", нажимает Ctrl+Enter, получает в гриде только записи начинающиеся на это слово.
а если в соседнем поле еще что написать, например тип: "вареная" (или просто "вар"), и только после этого нажать Ctrl+Enter, то список будет еще короче. :))

← →
Johnmen © (2003-05-15 13:04) [19]

>Zacho © (15.05.03 12:47)
>Об этих компонентах первый раз слышу, хотя стараюсь быть в курсе всего, связанного с IB.

А этот компонент (gb_DataSets ) никак не связан с IB.

> невозможно получить "последние" записи резалтсета без выборки всех предидущих

Строго говоря - невозможно. Но можно применить специальные приемы (как это делает BDE), чтобы получить конечные записи. Естественно, в этом случае выполнится не оригинальный запрос, а специально сгенеренный движком...

← →
Zacho © (2003-05-15 13:07) [20]

> Johnmen © (15.05.03 13:04)

Понятно.
Ну, тогда это не очень интересно.

← →
awex (2003-05-15 13:14) [21]

2Johnmen ©
>>>А этот компонент (gb_DataSets ) никак не связан с IB.
В смысле ???
что значит не связан?

2Zacho ©
>>в IB просто невозможно получить "последние" записи резалтсета >>без выборки всех предидущих, т.к. даже сам сервер "не знает", >>сколько записей выбрано запросом.

ВЫДЕРЖКА ИЗ README =

2. О НЕОБХОДИМОСТИ ДАННЫХ КОМПОНЕНТОВ

Технология, реализованная в "gb_DataSets Components", совсем не нова. По этой технологии написан TTable от BDE, который обкатывался годами. Таким образом, данную технологию можно считать надежной и проверенной. Суть ее сводится к
следующему. Допустим, имеется SQL-запрос следующего содержания:
select * from TABLE
order by FIELD
Выполнив его, и выполнив несколько раз fetch, мы получаем первые записи из таблицы TABLE. Допустим теперь, что нам надо посмотреть последние записи такого запроса. Решение "в лоб" - это делать fetch столько раз, сколько записей в таблице. Именно так поступают DataSet-компоненты как в IBX, так и в FIBPlus.
Однако если записей в TABLE миллион, то весь миллион и приедет на клиента, вызвав, практически, неработоспособность системы. Другое решение - это "похитрить". Можно выполнить "за кадром" другой запрос, начало которого будет гарантировано совпадать с последними записями первого.
select * from TABLE
order by FIELD DESC
Теперь делаем несколько раз fetch и получаем последние записи первого запроса. Произвольное позиционирование в любой точке x, будет выглядеть следующим образом:
select * from TABLE
where (FIELD = x)
Чтобы получить записи "выше" текущей:
select * from TABLE
where (FIELD < x)
order by FIELD DESC
"Ниже" текущей:
select * from TABLE
where (FIELD > x)
order by FIELD
Итак, запросов больше, fetch-ей очень мало. Практически, получаем систему с произвольным доступом к любой части таблицы TABLE. Но такая система накладывает и ряд ограничений, к счастью, не очень критичных. Во-первых, в первом запросе
выражение "order by" должно обязательно существовать. Поле FIELD должно быть уникальным. А для нормального быстродействия должны существовать по полю FIELD ДВА ИНДЕКСА (!!!) - по возрастанию (ASC) и убыванию (DESC). Подробнее существующие в "gb_DataSets Components" ограничения будут рассмотрены ниже.

← →
Zacho © (2003-05-15 13:22) [22]

> awex (15.05.03 13:14)

Все это хорошо, но, к, сожалению, применимо только для весьма простых запросов.
Кроме того, я придерживаюсь мнения, что в нормально спректированном приложении просто не должно быть "гридов с миллионами записей".

← →
awex (2003-05-15 13:47) [23]

2Zacho
Хорошо, может для визуализации в гриде может таких объемов и не нужно, но как быть когда в отчета нужно отобразить довольно большое количество записей ?
К примеру книга продаж за квартал (а таких подобных отчетов много) для средней крупности предприятия может достигать порядка тысячи страниц..... (мелким шрифтом...)

>>Все это хорошо, но, к, сожалению, применимо только для весьма >>простых запросов.
Хочешь, нехочешь а извращаться придется...

← →
awex (2003-05-15 13:49) [24]

2Zacho
Но, в любом случаее в "нормально спректированном приложении" должна быть возможность навигации по произвольному большому набору данных.

awex (15.05.03 13:47)
интересно, а как это поможет для отчета?
для отчета как раз, надо выгружать все записи.
А книга продаж на тысячу страниц... круто. :))
Я видел, что продажи группируют, делают одну фиктивную СФ в конце месяца, на всяких там частников, и т.д., вроде никаких проблем с налоговой.

>должна быть возможность навигации по произвольному большому
>набору данных.
угу, только надо стараться делать так, чтоыббыл как можно меньше этот самый надор данных - юзера спасибо скажут.

> awex (15.05.03 13:47)

Для отчетов это не нужно. Никакого повышения производительности не даст. Все равно на клиента придется фетчить все записи.

>awex (15.05.03 13:49)
>Но, в любом случаее в "нормально спректированном приложении"
>должна быть возможность навигации по произвольному большому
>набору данных.

Весьма спорное утверждение ! Или кавычки проставлены не случайно ? :))))))))

← →
Виталий Панасенко (2003-05-15 16:49) [28]

Для убыстрения рекомендуют построить DESC индексы по небходимым полям и, ПРИ ИСПОЛЬЗОВАНИИ BDE, скорость будет практически мгновенной, сам проверял на таблице из > 200 000 записей. Это я где-то на ibase.ru прочитал давненько

awex (15.05.03 13:47)
книга продаж за квартал ща квартал выполняется раз в квартал, к тому же желательно это делать в минимум нагрузки, скажем ночью.

← →
sts (2003-05-15 17:54) [30]

2 Zacho :

На счет отображения таблиц из миллионов записей и необходимости произвольного доступа к большим таблицам...

Интересно, почему в VCL нет DbTreeView ?... И сторонние разработчики реализуют по разному - т.е. отличаются они(компоненты) не внешним видом (как все DBGrid-ы), а именно внутренними механизмами доступа к данным и затачиваются часто под конкретную СУБД. Это, конечно, только в том случае, если не используется специальный вид таблицы хранящей дерево (под "не специальным" я подразумеваю таблицу с 2-мя обязательными полями: ID, ParentID).

Я думаю потому, что реализация (нормальная, без выфетчивания всех записей) требует как раз-таки произвольного доступа к таблице БД. вот тут и начинается : кэширование, формирование запросов,.... А наличие готовых компонентов в которых хотя бы Locate не вытягивает все записи позволяет не изобретать все это самостоятельно...

> sts (15.05.03 17:54)
> 2 Zacho :
>
> Интересно, почему в VCL нет DbTreeView ?...

<Много чего skip>

В первую очередь, потому, что разработчики БД реализуют хранение древесных структур по-разному. Ты же не думаешь, что ID - ParentID - это единственный способ ? И в разных СУБД есть разные механизмы работы с иерархическими структурами. В Oracle - connected by prior (если не ошибаюсь, уже плохо помню), в IB - рекурсивные ХП и т.д.

> Я думаю потому, что реализация (нормальная, без выфетчивания
> всех записей) требует как раз-таки произвольного доступа
> к таблице БД. вот тут и начинается : кэширование, формирование
> запросов,.... А наличие готовых компонентов в которых хотя
> бы Locate не вытягивает все записи позволяет не изобретать
> все это самостоятельно...

А я так не думаю. И думаю, что Locate к этому отношения практически не имеет. Возможно, я не прав, тогда объясни подробно, с примером.
И вообще, тогда почему нет стандартного DBTreeView для TTable ??? А ведь TTable работает именно так.

Вообще-то я не против таких компонентов, просто мне они мало интересны, и я - за нормальное проектирование клиент-серверных приложений, при котором такие подходы полезны только в редких случаях. Но, все-таки такие случаи могу быть, спорить не буду.

Немного добавлю.
Я не думаю, что компоненты типа gb_DataSets не нужны, или что они вредны. Наоборот, для некоторых задач они могут быть весьма полезны.
Но рекомендовать их применение как универсальную панацею в случае, когда разработчик просто не знает/не понимает технологию работы с клиент-сервером - явное зло.
P.S. Если у кого-нибудь есть желание продолжить тему - кажется, пора перебираться в "Потрепаться"

Paradox VS Interbase Найти похожие ветки