Wovan2

Если можно, я посмотрел бы.

Ну, сначала надо купить предмет испытаний

Скорость выборок и вставок поднять на текущей БД.

А знаете. По-моему все еще не совсем плохо. В принципе можно кое-какие манипуляции с БД произвести. Ведь если не трогать сами таблицы, то в работе клиента ничего не должно измениться (если, конечно, клиент не следит за изменениями структуры базы, что маловероятно, учитывая использование СУБД). Жаль, что у меня пока не на чем проверить.

У меня есть кой-какой опыт. Производственная программа работает уже 3 года. Правда на MSSQL. У меня проблема только с рисовалкой и двухмерной оптимизацией. Для этих целей используется внешняя считалка (Клаес, который фирма намеревается заменить ПСом, причем имеющиеся наработки планируется также сохранить (у нас внедрено штрихкодирование, полуавтоматизирован СГП)).

Привет. Может замутить свою прогу? На базе имеющейся БД.

Абсолютно верно. ФБ - серверная СУБД. Программа управляющая БД. И эту программу нужно и ДОЛЖНО использовать на полную катушку. Насчет падения надежности - не согласен. За надежность здесь ответственность несет ФБ. А ФБ вполне надежная система, способная следить и поддерживать состояние индексов. И процедуры типа реструктуризации, реализованные в программе для поддежки целостности данных, в принципе не нужны. Это забота ФБ. То, что сложность разработки возрастет - несомненно. Но также упростится и поддержка программы. Про скорость выборок уже и не говорю.

Привет. Я обратил внимание на строение БД только в контексте быстродействия, которое у программы оставляет желать лучшего. Именно архитектура БД впрямую влияет на скорость выборки данных. В частности грамотно сконструированные индексы и ключи могут в РАЗЫ увеличить скорость выборок. А неправильные индексы (или лишние индексы, или отсутствующие индексы) могут эту скорость также понизить. То что разработчик предпочитает всю логику и функциональность реализовывать в программе вопросов не вызывает. Это нормально (один из возможных вариантов). Но хотелось бы подвигнуть его к реструктуризации БД. Может в будущих версиях? По функциональности к программе претензий нет (почти нет).

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

Просмотрел несколько баз из разных источников. Выводы, к сожалению, не радужные:-( Возможности сервера БД практически не используются. На индексах, включающих строковые данные, сервер откровенно обалдевает. Как строятся планы запросов пока не разбирался. Но думаю там еще хуже. Итог: Firebird используется исключительно как простое хранилище данных с удобным доступом. Не более того. Путь к наращиванию аппаратных ресурсов (рекомедуемый Профстроем) - тупиковый. Боюсь, такая БД и на Oracle будет тормозить.

Меня интересовали изменения в оригинальной структуре БД (новые поля, индексы, триггеры и пр). А не сами данные

Привет. Тут заглянул в БД через менеджер firebird. Глаз резанули ключи в таблицах созданные из 4,5 и более полей. Так же в ключи попадают поля строкового типа. Причем в ключи входят и уникальные столбцы (которых, собственно, и достаточно для ключа). Индексов, кроме, автоматически созданных, нет. Ограничений целостности на уровне БД тоже нет. И почему используется диалект 1? Никто не пытался это понять? Может здесь проблема тормозов? А? Смотрел базу от ПС3, как мне сказали.

Извините. Я может пропустил. Изменения в структуру БД не вносятся? Это просто клиент ощающийся с БД?