Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

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

Выбор сервера БД? BDE -> ??? Помогите разобраться [D5, Paradox]


Страницы:   1 2

Armada ©   (2004-10-25 21:54:00) 

Тема похожа на уже обсуждавшуюся, но ...
Есть база данных. Paradox (BDE). Лежит на сети.
Все сетевые машины тормозят очень сильно!
Помогите разобраться. Приложение это набор справочников (9шт)
База (master) + 14 detail баз.
Сама master база копеечная, всего 1600 записей!!!
В detail базах по 3-10 записей привязаны к Master. Тоже мелочь.

Тормоза проявляются уже при простом переходе с записи на запись в главной базе. Что можно сделать, чтоб убрать такие тормоза?
Модернизацию железа не предлагать :)

Сервер Celeron 633 64Mb все остальные это зоопарк от 166 mmx до 1000Celeron.


Armada   (2004-11-05 20:16:00) [1]

msguns
>1. макс.эффективное использование индексов +
Везде читаю   эффективное использованиено пока нигде не нашел что это значит.
Нет индексов - плохо, много -плохо. Опять-же есть key ключ есть Secondary index. Поди разберись что и как МАКСИМАЛЬНО правильно использовать
>2. минимум открытых за раз деталов
 Это сделал. Но это только на форме. А что с отчетами делать?
Там-то все деталы нужны!!!
3. BDE
> Да, ту много нюансов. :)
4. оптимизация самой БД
(разобраться, может вместо 14 дочерних таблиц сделать 4 и т.д.)
Нет, это врятли возможно.


Armada   (2004-11-05 20:08:00) [2]

ЮЮ
>Я бы отношение 1..N постромл бы иначе:
>name         type  size key
>Id             I         *  
>N              S        
>и  secondary index по N

Что изменится при добавлении лишнего поля и secondary index?


Mike Kouzmine   (2004-11-05 14:35:00) [3]

msguns ©   (05.11.04 12:31) [33] Извини. Ты как всегда прав. :)


msguns   (2004-11-05 12:31:00) [4]

>Mike Kouzmine ©   (05.11.04 11:48) [32]

Миха, читани [19] и [25]

С парадоксом все ж ясно: макс.эффективное использование индексов + минимум открытых за раз деталов + BDE + оптимизация самой БД (разобраться, может вместо 14 дочерних таблиц сделать 4 и т.д.)


Mike Kouzmine   (2004-11-05 11:48:00) [5]

msguns ©   (05.11.04 11:16) [31]
1 Для парадокса IBX не родные компоненты.
2 ХП из той же оперы
3 То же самое
4 От него не зависит почти


msguns   (2004-11-05 11:16:00) [6]

Тормозов будет куда меньше, если
1) Перейти на родные компоненты (вместо BDE юзать IBX)
2) Максимально "утоньшить" клиента, вынеся большинство "тяжелых" запросов в ХП или View
3) Грамотно использовать транзакции
4) Оптимизировать интерфейс таким образом, чтобы не тянуть лишнее с сервера.


Mike Kouzmine   (2004-11-05 10:56:00) [7]

Тормоза уберуться если отказаться от TQuery и перейти на TTable и использовать связь мастер-детайл.


ЮЮ   (2004-11-05 06:06:00) [8]

и вторичный ключ по N следует читать как secondary index


ЮЮ   (2004-11-05 06:05:00) [9]

Ну, тогда уж, и не знаю, чем помочь.

>Сервер Celeron 633 64Mb все остальные это зоопарк от 166 mmx до 1000Celeron.
>Поможет ли переход от файл-серверной платформы (BDE+Paradox)
К клиент серверным технологиям (Возможно Fireberd)

Очевидно, да. Т.к. в случае с парадоксом, все работа с БД выполняется на клиенте и мощности сервера здесь практически ни при чем. При клиент-серверной технологии основная нагрузка ляжет на сервер, а не на зверей из зоопарка (после того, как у нас MS SQL поставили на нормальное железо, программа стала летать и на P133, хотя до этого на них сильно тормозила)

З.Ы. Правда, 64Mb на сервере - тоже не разгуляешься  

З.З.Ы.
Я бы отношение 1..N постромл бы иначе:

name         type  size key
Id             I         *  
N              S        
tat            a     20  
text           a     50

и вторичный ключ по N


armada   (2004-11-04 22:37:00) [10]

base2.db
name         type  size key
N              S         *
tat            a     20  *
text           a     50

secondary index - пусто.


ЮЮ   (2004-11-04 03:03:00) [11]

Индекс по n у base2 есть?


armada   (2004-11-03 22:32:00) [12]

Почему приложение начинает СИЛЬНО тормозить при подключении хотя-бы одной detail- базы.?

Master: select * from base
detail: select * from base2 where n=:n

что еще нужно указать?

Обработчиков After и BeforeScrol нет.

Поможет ли переход от файл-серверной платформы (BDE+Paradox)
К клиент серверным технологиям (Возможно Fireberd)


Anatoly Podgoretsky   (2004-10-30 11:53:00) [13]

armada   (29.10.04 23:22) [23]
Чтобы получить правильный ответ в овпросе должно быть более половины ответа, так что продолжай вариться.


armada   (2004-10-29 23:22:00) [14]

>Заменил Master->Detail на Filter подчиненных баз

> Т.е. перешел от TQuery к TTable,
  :) Нет, я оказался ленивым, заюзал Filter от Query.
> а ещё о переходе на SQL-server мечтаешь :)
 :) Видимо я криво спрашивал, но ничего вразумительного мне не ответили, поэтому придется продолжать варится в собственном соку.


ЮЮ   (2004-10-29 06:36:00) [15]

>Заменил Master->Detail на Filter подчиненных баз

Т.е. перешел от TQuery к TTable, а ещё о переходе на SQL-server мечтаешь :)


armada   (2004-10-29 01:33:00) [16]

Вопрос временно решился.
Главный тормоз Это переоткрытие деталов. Если на форме лежал хоть один детал, приложение тормозило уже при переходе с записи на запись. Заменил Master->Detail на Filter подчиненных баз. И проблема почти исчезла.


msguns   (2004-10-28 09:36:00) [17]

IBX (Есть в дельфи), FIBPlus


armada   (2004-10-28 08:19:00) [18]

Какие компоненты доступа лучше использовать для доступа к Firebird?


armada   (2004-10-27 19:38:00) [19]

To Erik1
>Только компоненты доступа лучше поменять, хотя для твоего
 Напрмер на что?

msguns
Везде используется Query

14 деталов 100% откроются при создании отчета.
Да, все гриды не видны, часть могу закрыть.
Но тогда следующий вопрос будет на тему "Создание отчета затянулось на xxx минут". Навигация приведена для примера. Ибо тормоза уже здесь.
Просмотрел все Query на предмет AfterScroll BeforeScroll.
Только в гласной базе в BeforerScroll есть одна команда:

F1:=EXEName+'Photo\'+QBase.FieldbyName('N').AsString+'_f.BMP';

Field.OnGetText - нигде не используются.


msguns   (2004-10-27 12:05:00) [20]

Согласен с АП,- дело не в "движке". Что-то в самой логике. Например, криво обрабатывются события датасетов (AfterScroll, Field.OnGetText  и т.д.). Существенно тормозить будут и длинные поля связок, даже если они ключевые для деталов (например стринговые)
Ну и по сути проблемы, конечно, есть вопросы.
1. Зачем держать одновременно 14 открытых деталов ?
2. Какие компоненты доступа все же юзаются (TTable, TQuery или еще что-то - поподробнее плз)


Страницы:   1 2

Наверх

Титульная страница Поиск, карта сайта Написать письмо