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

← →
Armada (2004-10-25 21:54) [0]

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

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

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

← →
Submarine (2004-10-26 07:10) [1]

Проблема может быть самая разнообразная:
1. Неправильно построины запросы
2. Настрой общий Net dir, например T:\PDXNETDR
где t- сетевой диск.

← →
sniknik © (2004-10-26 08:30) [2]

14 связанных таблиц в запросе, далеко не мелочь. при обьеденении строится декартово произведение таблиц (всех со всеми) после по условию отсекаются лишнии. (так оно работает)
т.ю. получатся 1600 зап. * 10 зап = 16000 зап (одно обьеденение), 160000 (следующее со 10 записями), и т.д.
но это только тормоза на открытии запроса должны быть.
а на переходе по записям, больше похоже на слет/отсутствие индексов, либо действительно логика работы "нестандартная" (через задницу ;о)).

> Что можно сделать, чтоб убрать такие тормоза?
можно поменять парадокс на sql сервер (любой) и логику работы с файл серверной на клиент серверную, тормоза убираются с гарантией. (при оставлении логики наоборот добавляются ;о))

← →
ЮЮ © (2004-10-26 08:50) [3]

>База (master) + 14 detail баз.

И как размещаются эти пятнадцать гридов на экране? Всё сразу видно? А если нет, то избавься от лишних накладных расходов по установлению master-detail связей для невидимых пользоваиелю таблиц

← →
Anatoly Podgoretsky © (2004-10-26 09:18) [4]

sniknik © (26.10.04 08:30) [2]
Наоборот стандартная

← →
Sergey13 © (2004-10-26 09:23) [5]

2Armada (25.10.04 21:54)
>Тормоза проявляются уже при простом переходе с записи на запись в главной базе.
Может что то выполняется в этот момент?
Для такой структуры SQL запросы, ИМХО, будут только тормозов добавлять. Тут, по моему, целесообразнее делать лукап поля.

← →
armada (2004-10-26 21:07) [6]

To Submarine
>Проблема может быть самая разнообразная:
>1. Неправильно построины запросы
>2. Настрой общий Net dir, например T:\PDXNETDR
>где t- сетевой диск
Факи, и маны по BDE изучены хорошо. NetDir общий.

To Sergey13
> Может что то выполняется в этот момент?
Нет, не выполняется. Лукапы где можно там используются, а как через lookup задать несколько подчиненных записей ?

To sniknik

← →
armada (2004-10-26 21:21) [7]

To sniknik
Присмотрел FireBird. Кстати в нем поддерживаются подзапросы типа
select n from base where n in (select n ...)?
> (при оставлении логики наоборот добавляются ;о))
Что ты имеешь в виду под логикой? Тут при простой навигация тормозит. А запуск отчета по всей базе это ... :(

← →
sniknik © (2004-10-26 22:17) [8]

> Кстати в нем поддерживаются подзапросы типа ...
и подзапросы и многое другое.

> Что ты имеешь в виду под логикой?
логика это логика, то как у тебя все организовано.
если ты к примеру в клиент серверной используеш таблицы, то считай ее у тебя нет, однозначно. но даже если используеш только запросы это не значит что она у тебя появилась ;о).
встречал к примеру такое
после запроса
select * from table
чтение в переменную
count:= query.recordcount;
это как понимаш, узнают количество записей в таблице. и больше результат запроса нигде (!!!) не используется, количество единственная цель, и автор уверено так говорил "все правильно я же запросы использую!". (а чего же она тормозит?) ;о)
так вот если у тебя есть чтото хоть отдаленно похожее, все, крест на логике.
и даже если явных ляпов не сделаеш, а некоторые запросы если логично подумать, можно в несколько раз быстрее переписать... если можно то все тоже не вполне логично.
а вот когда это уже становится невозможным (оптимизация в несколько раз, а можно только на пять/десять в особых случаях двадцать процентов, да и то если поднапрячся), вот тогда можно говорить, у тебя в программе появилась логика. ;о)

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

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

← →
armada (2004-10-26 23:14) [9]

>select * from table
>чтение в переменную
>count:= query.recordcount;
>так вот если у тебя есть чтото хоть отдаленно похожее, все, >крест на логике.

Хорошо, база открывается
select n, fio, ..... from base
Все остальные базы (14) открываются как
select * from baseN where n=:n
Здесь логика есть? Откуда в такой связке тормоза при простой навигации? (Клики по DbNavigator). Увеличится ли скорость работы при переходе на FireBird?

← →
sniknik © (2004-10-27 00:34) [10]

> Хорошо, база открывается ...
дозируем информацию?
ну ладно скажу еще чуть чуть
по капле выдавливать нужно из себя раба, а не инфу, особенно непосредственно относящуюся к вопросу, который интересует заметь в основном тебя.

> Здесь логика есть? Откуда в такой связке тормоза при простой навигации?
зависит не только от запросов а еще и то откуда и как они выполняются. в общем то я могу предположить в каком случае при таких запросах будет тормозить но не буду.
наводяший вопрос
> select n, fio, ..... from base
выбираются все записи, они все нужны? поиши ответ в книжках.

← →
ЮЮ © (2004-10-27 02:40) [11]

>Все остальные базы (14) открываются как
select * from baseN where n=:n

Открыты все сразу, независимо от того отображаются на экране или нет? Во всех поле n проиндексировано?
Ведь при "простой навигации", как минимум, выполняютя 14 этих самых запросов select * from baseN where n=:n.

← →
Erik1 © (2004-10-27 11:10) [12]

Да ладно вам 1600 записей это ерунда, вобщем поставь IB(FireBind) и немучайся. Только компоненты доступа лучше поменять, хотя для твоего случая можно и BDE оставить. Попробуй, делов то на 1 час.

← →
Плохиш © (2004-10-27 11:15) [13]

А что в Paradox-е разве не перекачиваются все необходимые данный на локальную машину, а уже потом обрабатываются запросы?

← →
Anatoly Podgoretsky © (2004-10-27 11:20) [14]

Перекачиваются, поэтому запросы работают заметно быстрее, чем навигационные методы.

← →
ЮЮ © (2004-10-27 11:38) [15]

>Anatoly Podgoretsky © (27.10.04 11:20) [14]

Серьезно? Т.е. select * from baseN where n=:n перекачает всю baseN, а затем быстрее найдет одну запись?

← →
Anatoly Podgoretsky © (2004-10-27 11:42) [16]

А у него не в этом проблема, а в том, что у него при каждом перемешении по сетке, выполняются 14 таких запросов.
Вот с чем надо бороться, при установке SQL сервера будет еще медленнее.

← →
msguns © (2004-10-27 12:05) [17]

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

← →
armada (2004-10-27 19:38) [18]

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

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

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

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

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

← →
armada (2004-10-28 08:19) [19]

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

← →
msguns © (2004-10-28 09:36) [20]

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

← →
armada (2004-10-29 01:33) [21]

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

← →
ЮЮ © (2004-10-29 06:36) [22]

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

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

← →
armada (2004-10-29 23:22) [23]

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

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

← →
Anatoly Podgoretsky © (2004-10-30 11:53) [24]

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

← →
armada (2004-11-03 22:32) [25]

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

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

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

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

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

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

← →
armada (2004-11-04 22:37) [27]

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

secondary index - пусто.

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

>Сервер 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

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

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

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

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

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

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

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

← →
Armada (2004-11-05 20:08) [35]

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

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

← →
Armada (2004-11-05 20:16) [36]

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

Выбор сервера БД? BDE -> ??? Помогите разобраться Найти похожие ветки