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

to Fedia
Клиентское приложение у всех одинаковое, так называемый толстый клиент, т.е. различные права по отделам распределены прямо в клиентском приложении. Запросов много и много проверок между ними. пример одного из запросов (остальные имеют схожую структуру):


to superVad
У меня не столь крутые задачи, чтобы менять платформу, мне надо найти недочёты чтобы увеличить производительность, но всё равно спасибо!

to Alex
Факи прочитал, всё проверил, вроде явных ошибок у меня нет

DataBase Cach (pages) 2048
Client map size (bytes) 4096
как думаешь увеличить?
если да, то можно не останавливать работу, а прямо во время, ничего не случится?

to DimW
философия на тему типа БД мне не поможет
у меня очень конкретный вариант.
это похоже на выражени "Сколько людей - столько мнений" - выражение без смысла, т.к.
решение всё равно принимают общее, так вот мне нужно решение. Без обид!
Задача как у всех - склад + бухгалтерия.
спасибо

samurai, Есть возможность посмотреть загруженность процессора сервера БД и процент используемой ОЗУ во время интенсивной работы пользователей ? Если ресурсы используются по полной программе, то тут уже придется думать об оптимизации структуры БД и таблиц.
Не знаю, есть ли аналог MySql  функции explain для Interbase. Если есть, то все запросы к БД, по хорошему, нужно пересмотреть при помощи аналога explain.

и посмотреть, используются ли для обработки данного запроса индексы, количества строк, которые будут перебираться при формировании ответа на запрос, длину ключа и др. параметры. Ну а дальше действовать по обстоятельствам. Н-р: если не используется индекс и запрос выполняется долго, то можно либо создать необходимый для ускорения запроса индекс (пожертвовав местом на HDD сервера) или же изменить запрос, так, чтобы он использовал уже существующие индексы.
Это кропотливая работа, но ИМХО необходимая для оптимизации клиентских приложений в случае, если они сверх меры нагружают сервак   Бог в помощь.

еще раз процетирую:

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


а вот мне в свое время помогла, только не философия это а теория, а прежде чем приступить к практике теорию нужно знать.


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


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

DimW, 
Ходить на лекции, оно конечно хорошо. Только чудесатое разделение на 

я ни у одного из классиков типа Дейта, Бойса, Кодда, Ульмана не встречал. Так что это разделение - на совести лектора или твоей (последнее более правдоподобно). И нафиг оно никому не нужно. Поскольку СО ВСЕМИ СЕРВЕРАМИ РАБОТАЮТ ЧЕРЕЗ ТРАНЗАКЦИИ и никак иначе. Они по-другому просто не умеют. 
Вдогонку: не надо коверкать русский язык. Т.е. писать с грубыми ошибками - не уважать самого себя.

samurai, 
Сходи на www.ibase.ru и почитай про версионность. Судя по тому, что у тебя с начала работы в течение дня скорость падает - увеличивается количество версий записей, и соответственно все больше времени уходит на актуализацию. Т.е. слишком поздно делаешь commit.

Главное "заведи" сервер на один процессор, что бы он не шастал по всем у тебя 4-ем и размер кеша м кол-ва страниц можно увиличить.

PS:
Ваша задача это мелочь в принципе для IB

в этом все и дело что это классики, они описывают правельные БД - нормалезованные, и учат контролировать данные при помощи всевозможных констрейтов, тригеров и чем больше их тем лучше! Вот такие любители классической литературы напроектируют баз данных, а потом расхлебывай заними!  
Избыточность индексов - это одна из причин снижениея производительности сервера БД.


Вовсе нет, т.к. лекторы как и вы начитаются классиков и живут в розовом цвете...

так что в вашем понимании транзакция?! любое обрашение к БД? если так, то очень вас жаль!
Транзакцией называют любой sql-запрос который нацелен на модификацию как объектов БД, так и данных. Sql - запросы возвращающие наборы данных не являются транзакциями! а те транзакции которые вы имеете ввиду - называются сессиями БД!
ну так вот те БД которые используются для получения информации называются аналитическими(предпологается что данные накапливались в БД ранее, или транзакций на порядок меньше чем возврата данных).
   
SergeBS, вдогонку:  читайте дальше Дейта, Бойса, Кодда, Ульмана и будет вам счастье, во могу даже дать телефон моего бывшего лектора, вы с ним поладите!!!    

Это сообщение отредактировал(а) DimW - 6.8.2006, 10:38

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

Дайте нам не грамотным определение сессии БД

Ты сам говоришь, что нормализованные БД - правильные. И для подтверждения этого факта можно привести множество аргументов ! 


Зачем ты так пишешь? Принцип чем больше, тем лучше относиться к прибыли, но никак не к БД. Определение "нормализованная БД" совсем не подразумевает наличия в БД большого количества индексов и триггеров. Если ты об этом знаешь, то к чему такие высказывания ? Всего должно быть в меру, для обеспечения быстрого и надежного функционирования БД ! Классики бы на тебя затаили большую обиду 

я не говорю что вы не грамотные!
сессиея(соединение) - это период времени от подключения к БД до отключения.
в одной сессии может вызываться множество транзакций.

вобще я не понял что вас так задело?! что я не правельно написал?
 
samurai, спросил

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

я не говорю что у samurai в БД избыточность, я лишь предпологаю что может быть такое. 
Alex,  на счет тригеров я погорячился. сам их уважаю и использую, но в меру  .

Как же хочется отправить вас почитать литературу прежде чем высказываться... Запрос - это транзакция, ужас.



Да, что вы говорите, а про уровни изоляции транзакций, версиональность данных вы слышали?

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

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

Просто хочу уточнить. Что вкладывается в понятие блокировочник ? Ты имеешь в виду СУБД у которых бликирутся модифицируемые таблицы при внесении изменений в БД ?

да.