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

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

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

Paradox VS Interbase

Страницы: 1 2 >
Alexei Sviridov © (2003-05-14 14:44:00)
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

Zacho (2003-05-15 22:53:00) [1]
Немного добавлю.
Я не думаю, что компоненты типа gb_DataSets не нужны, или что они вредны. Наоборот, для некоторых задач они могут быть весьма полезны.
Но рекомендовать их применение как универсальную панацею в случае, когда разработчик просто не знает/не понимает технологию работы с клиент-сервером - явное зло.
P.S. Если у кого-нибудь есть желание продолжить тему - кажется, пора перебираться в "Потрепаться"

Zacho (2003-05-15 21:38:00) [2]

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

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

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

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

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

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

sts (2003-05-15 17:54:00) [3]
2 Zacho :

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

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

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

Anatoly Podgoretsky (2003-05-15 16:59:00) [4]
awex (15.05.03 13:47)
книга продаж за квартал ща квартал выполняется раз в квартал, к тому же желательно это делать в минимум нагрузки, скажем ночью.

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

Johnmen (2003-05-15 14:05:00) [6]
>awex (15.05.03 13:49)
>Но, в любом случаее в "нормально спректированном приложении"
>должна быть возможность навигации по произвольному большому
>набору данных.

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

Zacho (2003-05-15 13:56:00) [7]

> awex (15.05.03 13:47)

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

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

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

awex (2003-05-15 13:49:00) [9]
2Zacho
Но, в любом случаее в "нормально спректированном приложении" должна быть возможность навигации по произвольному большому набору данных.

awex (2003-05-15 13:47:00) [10]
2Zacho
Хорошо, может для визуализации в гриде может таких объемов и не нужно, но как быть когда в отчета нужно отобразить довольно большое количество записей ?
К примеру книга продаж за квартал (а таких подобных отчетов много) для средней крупности предприятия может достигать порядка тысячи страниц..... (мелким шрифтом...)

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

Zacho (2003-05-15 13:22:00) [11]

> awex (15.05.03 13:14)

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

awex (2003-05-15 13:14:00) [12]
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:07:00) [13]

> Johnmen © (15.05.03 13:04)

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

Johnmen (2003-05-15 13:04:00) [14]
>Zacho © (15.05.03 12:47)
>Об этих компонентах первый раз слышу, хотя стараюсь быть в курсе всего, связанного с IB.

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

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

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

Danilka (2003-05-15 12:52:00) [15]
видел, например, быстрый поиск по наименованию, пользователь пишет название продукта, начало, например: "колба", нажимает Ctrl+Enter, получает в гриде только записи начинающиеся на это слово.
а если в соседнем поле еще что написать, например тип: "вареная" (или просто "вар"), и только после этого нажать Ctrl+Enter, то список будет еще короче. :))

Zacho (2003-05-15 12:47:00) [16]

> awex (15.05.03 11:46)

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

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

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

Alexei Sviridov (2003-05-15 12:33:00) [18]

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

Ne podskazhite gde ego vzjat?

Alexei Sviridov (2003-05-15 12:30:00) [19]

> 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...

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

Страницы: 1 2 >

Наверх

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