Структура БД

[Wovan2]

Привет.

Тут заглянул в БД через менеджер firebird.

Глаз резанули ключи в таблицах созданные из 4,5 и более полей. Так же в ключи попадают поля строкового типа.

Причем в ключи входят и уникальные столбцы (которых, собственно, и достаточно для ключа).

Индексов, кроме, автоматически созданных, нет.

Ограничений целостности на уровне БД тоже нет.

И почему используется диалект 1?

Никто не пытался это понять?

Может здесь проблема тормозов? А?

Смотрел базу от ПС3, как мне сказали.

[Wovan2]

Просмотрел несколько баз из разных источников.

Выводы, к сожалению, не радужные:-(

Возможности сервера БД практически не используются.

На индексах, включающих строковые данные, сервер откровенно обалдевает.

Как строятся планы запросов пока не разбирался. Но думаю там еще хуже.

Итог: Firebird используется исключительно как простое хранилище данных с удобным доступом.

Не более того.

Путь к наращиванию аппаратных ресурсов (рекомедуемый Профстроем) - тупиковый.

Боюсь, такая БД и на Oracle будет тормозить.

[Rexther]

Просмотрел несколько баз из разных источников.

Выводы, к сожалению, не радужные:-(

......

Боюсь, такая БД и на Oracle будет тормозить.

Ну и как? Связались с ПрофСегментом, поведали им о своих мыслях... каков ответ?

что дальше-то?

[Wovan2]

Ни с кем я не связывался.

Мы эту программу еще не купили.

Только рассматриваем в качестве кандидата. Впрочем, последнего кандидата.

Из общений с Профсегментом вынес одно, пока программа не приобретена, никаких разговоров по существу они не ведут.

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

Поэтому мой пост стал чисто риторическим. Неужели НИКТО на ЭТО не обратил внимания. Неужели ни в одной фирме нет программистов, знакомых хотя бы с основами проектирования реляционных БД.

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

Хочется привести аналогию такого использования СУБД.

У нас есть автоматизированный склад с многоэтажными стеллажами, с роботами-манипуляторами, которые сами могут складывать вещи, находить и приносить к выходу все, что нам требуется (это Firebird, в нашем случае). А мы его используем, как простой сарай. Забиваем его, всяким барахлом как попало. Потом пытаемся, что-то найти, а тут еще всякие умные железки под ногами, провода путаются. В общем мешают. Поиск затягивается. А виноват кто? Роботы.

Вот такие пироги.

Edited January 23, 2009 by Wovan2

[SirAlex2]

...Вот такие пироги.

 

Смотрел структуру БД Профстроя, только Профстроя2 версия ПрофОкна - картина по использованию СУБД такая же. Т.е. в 3-ей версии преемственность сохранилась. Интересно, как в других прогах СО или Альтавин? На самом деле, Профстрой в разных версиях работает на многих фирмах. Рекомендую остановится на бесплатной версии - ПрофОкне, в большинстве случаев устроит. Недостатки в БД несильно потянут в железе. Для оптимизации БД используйте IBExpert или другие утилиты администрирования, лично я не заморачивался с триггерами и пр. просто ввел в БД необходимые для меня таблицы.

[Rexther]

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

 

Так вот вопрос: а что, собственно говоря может еще делать FB, кроме как хранить данные? Какие от него могут потребоваться обработки? Я так понимаю, что все обработки выполняет сам ПС...

[Xynter]

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

 

Так вот вопрос: а что, собственно говоря может еще делать FB, кроме как хранить данные? Какие от него могут потребоваться обработки? Я так понимаю, что все обработки выполняет сам ПС...

 

 

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

Во-вторых, можно так же написать процедуры, которые расширят функционал триггеров, и еще написать на любом языке внешние функции реализованные в dll ну и так далее...

[Rexther]

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

Во-вторых, можно так же написать процедуры, которые расширят функционал триггеров, и еще написать на любом языке внешние функции реализованные в dll ну и так далее...

 

Т.е. я понимаю, что FB (в моем понимании программа управления базой данных) может самостоятельно (отдельно от программы) управлять этой самой базой. Т.е. кроме программирования ПО автор должен еще и программировать FB, т.е. получается, что комплекс усложняется, приобретает многомерность, а стало быть общая надежность СИСТЕМЫ в целом снижается.

[Xynter]

Т.е. я понимаю, что FB (в моем понимании программа управления базой данных) может самостоятельно (отдельно от программы) управлять этой самой базой. Т.е. кроме программирования ПО автор должен еще и программировать FB, т.е. получается, что комплекс усложняется, приобретает многомерность, а стало быть общая надежность СИСТЕМЫ в целом снижается.

 

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

 

сама FB самотоятельно управлять БД не может...только тем интсрументом что человек написал....

[SirAlex2]

Т.е. я понимаю, что FB (в моем понимании программа управления базой данных) может самостоятельно (отдельно от программы) управлять этой самой базой. Т.е. кроме программирования ПО автор должен еще и программировать FB, т.е. получается, что комплекс усложняется, приобретает многомерность, а стало быть общая надежность СИСТЕМЫ в целом снижается.

Это выбор разработчика использовать свое ПО для управления данными или пользоваться встроенными средствами FB, или какой-то комбинированный вариант. При использовании процедур обработки средствами FB, обычно, как раз повышается и надежность системы и ее быстродействие. В этом случае пользователь, получая БД, получает еще и какой-то инструмент работы с этими данными. Да, как сказал Xynter,

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

[Wovan2]

Привет.

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

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

То что разработчик предпочитает всю логику и функциональность реализовывать в программе вопросов не вызывает. Это нормально (один из возможных вариантов). Но хотелось бы подвигнуть его к реструктуризации БД. Может в будущих версиях?

По функциональности к программе претензий нет (почти нет).

[Wovan2]

Т.е. я понимаю, что FB (в моем понимании программа управления базой данных) может самостоятельно (отдельно от программы) управлять этой самой базой. Т.е. кроме программирования ПО автор должен еще и программировать FB, т.е. получается, что комплекс усложняется, приобретает многомерность, а стало быть общая надежность СИСТЕМЫ в целом снижается.

 

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

Насчет падения надежности - не согласен. За надежность здесь ответственность несет ФБ. А ФБ вполне надежная система, способная следить и поддерживать состояние индексов. И процедуры типа реструктуризации, реализованные в программе для поддежки целостности данных, в принципе не нужны. Это забота ФБ.

То, что сложность разработки возрастет - несомненно. Но также упростится и поддержка программы. Про скорость выборок уже и не говорю.

Edited January 26, 2009 by Wovan2

[SergOld]

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

Насчет падения надежности - не согласен. За надежность здесь ответственность несет ФБ. А ФБ вполне надежная система, способная следить и поддерживать состояние индексов. И процедуры типа реструктуризации, реализованные в программе для поддежки целостности данных, в принципе не нужны. Это забота ФБ.

То, что сложность разработки возрастет - несомненно. Но также упростится и поддержка программы. Про скорость выборок уже и не говорю.

 

Доброго дня суток.

 

В СО с производительностью все в порядке. Там используется диалект 3, а не 1, как в ПС, и активно используются хранимые процедуры и функции, триггера. То есть возможности базы используется по полной программе.

А в ПС 3 все осталось как в Профокнах - видимо разработчикам было лениво что-либо переписывать, а функционал существенно возрос - вот и дополнительные тормоза на и так не самую производительную программу Профокна.

[MOHTEP]

Приветствую, граждане.

 

По поводу БД (структуры, архитектуры и т.д.)

Там я уже изливал свои замечания....

Как я понимаю к таким людям есть ответ в ФАКе Профсегмента

тынц

То есть одним словом "Не гундите"

 

По этому поводу разговаривал я с Сергеем Васильевым из Профсегмента и по почте и при личной встрече, и даже еще на обучении (а это были первые пару часов общения с программой)

 

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

Передавал их программистам ссылки (через Сергея) на Маны работы с FB

IBX

работа с транзакциями

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

 

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

 

А к вопросу Рекстера о функциях СУБД скажу одну весчь: как вы оцениваете "программистский ресурс" команды разработки FB и их опыт в оптимизации и "тот же ресурс" компании Профсегмент с их от силы-двумя тремя разработчиками на направлении ПС (а то и не на одно направление на них висит)?

А возможности по тестированию разработок?

А капитализацию проектов?

 

А теперь вспомним, что таблицы в базе ПС все равно логически связаны между собой. Между записями есть логические зависимости. То есть вместо готового инструмента FB по реализации связей (например проект - контрагент), или целостности (нельзя удалить контр агента, пока за ним числятся проекты), инструмента который оттестирован оптимизирован и интегрирован в СУБД, который будет централизованно выполняться на сервере (ТО ЕСТЬ БЫСТРЕЕ И НАДЕЖНЕЕ, сервер то Профсегмент требует по спецификации ого-го), Профсегмент изобретает свой собственный велик с семью колесами (и шестью запасками), 2 из которых не достают до земли, а для ног всего одна педаль. При этом весь этот колхоз они заставляют работать на клиентских (обычно более слабых) компьютерах, и при этом гонять по сети дополнительный траффик (у кого сетевые версии).

 

Повторю ситуацию в ПС3: для генерации новых ID для записей в таблице используется схема max(id)+1. Такая схема для сетевых приложений категорически запрещена, так как является рассадником дубликатов идентификаторов. Во всех современных СУБД для этого существует механизм генераторов. А нам что до них до этих СУБД - да наплевать. Мы лучше знаем, что нужно нашим клиентам. И ничего "пипл хавает". Накладные если создавать на трех раб местах одновременно - просто сказка.

 

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

 

 

 

 

Из всего сказанного - если и брать у Профсегмента ПС3 на сеть и множество пользователей (ну скажем больше 5-10)- то только "под-ключ", пускай дороже (нет я не рекламирую и не агитирую - наболело), но при этом требовать офф. гарантий на развернутый проект. Чтобы не было отмаз по поводу наводок в сетевом кабеле и последующей потери информации на системе с терминальным доступом, как было у меня. Или "у нас ситуация не повторяется - ищите ошибку сами". Или вот еще тоже не плохой ответ: "зайти к вам в терминал мы не можем - у нас интернет медленный - покупайте у нас доп техподдержку - тогда поговорим" это на окритическую ошибку при которой вываливается accessviolation.

Edited January 29, 2009 by Rexther
удалена ссылка на профиль пользователя

[Rexther]

МОНТЕР.

Я написал в самом начале, что не являюсь специалистом по СУБД, я не программер. Спорить с кем бы то ни было на тему методик управления СУБД не стану - это было бы глупо с моей стороны.

 

Но есть момент о котором я Вам поведаю.

Обратите внимание на тон дискуссии, разговора, который был в этой теме ДО Вашего появления. Поясню - тут был спокойный разговор-обсуждение. И даже мне, не специалисту, тут нашлось место и мне ответили. А вот разного рода обвинениям тут места не было и не будет, я надеюсь, в дальнейшем.

Так, что рекомендую сбавить тон и успокоиться.

 

Теперь по вопросу ПС. Никто из нас не знает по какой причине разработчики ПС выбрали именно такой путь, которым следуют. Никто из тут присутствующих не имеет на данный момент программы, которая эксплуатируется в нескольких сотнях организаций, никто не занимается поддержкой такого продукта и не несет за это ответственности.

Ваш, МОНТЕР, пример с написанием собственного приложения на страницах этого форума продемонстрировал как не просто это. Насколько я понимаю Вам пришлось уже переписать продукт заново? Наверно что-то не было учтено в самом начале? Наверно появились мысли о том как улучшить продукт?....

Так вот оцените сложность положения ПрофСегмента в этом разрезе.

 

Вы пришли сразу на ПС3, как я понял. А я осуществлял переход с ПС2 на ПС3 и не понаслышке знаю каков это был труд. Мне пришлось переписать всю базу заново. В условиях работающего предприятия это не тривиальная задачка, уверяю Вас. Так вот я знаю, что такой сложный переход это не прихоть разработчика, а как раз настоятельная необходимость внесения определенных изменений и улучшений в программу. Только вот эти изменения и улучшения оказались слабо совместимы с тем, что было раньше.

 

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

Опять же есть вот какой момент: FB сторонняя программа. Конечно в ней наверно поддерживается преемственность от версии к версии. Но может разработчики ПС решили использовать ее только как хранилище, что бы не зависеть от возможных изменений в ней, не быть заложниками возможных изменений не контролируемых ими? (Это не более, чем мое предположение, но и оно наверно имеет право на существование.)

 

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

 

Применительно к общению с разработчиками из ПрофСегмента я с уверенностью могу констатировать простой факт: тот кому нужен контакт и работа - тот все получит и найдет понимание. Знаю это на своем опыте, многолетнем. Не подводили меня ребята из ПрофСегмента. Не без проблем все было, но тем не менее.

[MOHTEP]

МОНТЕР.

Я написал в самом начале, что не являюсь специалистом по СУБД, я не программер. Спорить с кем бы то ни было на тему методик управления СУБД не стану - это было бы глупо с моей стороны.

Я вижу, что вы высказали свое предположение. И своим комментарием я попытался объяснить неправильность подхода, выбранного разработчиками Профсегмента. То есть я вас не обвиняю в том что вы не понимаете, как раз обяснял таким образом.

 

Но есть момент о котором я Вам поведаю.

Обратите внимание на тон дискуссии, разговора, который был в этой теме ДО Вашего появления. Поясню - тут был спокойный разговор-обсуждение. И даже мне, не специалисту, тут нашлось место и мне ответили. А вот разного рода обвинениям тут места не было и не будет, я надеюсь, в дальнейшем.

Так, что рекомендую сбавить тон и успокоиться.

Хех. Чесное слово никого не хотел ни обидеть, ни тем более оскорбить. Тон мой, хм... это скорее общее настроение... Не судите строго. ибо наболело. Разжигать нацрознь не собирался . А вот право обвинять кого либо все же оставьте, так как это мнение высказанное мной лично, оно основывается на фактах из моего опыта не придуманы. Обвинение - не есть оскорбление.

 

Теперь по вопросу ПС. Никто из нас не знает по какой причине разработчики ПС выбрали именно такой путь, которым следуют. Никто из тут присутствующих не имеет на данный момент программы, которая эксплуатируется в нескольких сотнях организаций, никто не занимается поддержкой такого продукта и не несет за это ответственности.

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

 

Ваш, МОНТЕР, пример с написанием собственного приложения на страницах этого форума продемонстрировал как не просто это. Насколько я понимаю Вам пришлось уже переписать продукт заново? Наверно что-то не было учтено в самом начале? Наверно появились мысли о том как улучшить продукт?....

Так вот оцените сложность положения ПрофСегмента в этом разрезе.

Тут тоже поясню. "Переписывание" программы есть не что иное как "рефакторинг". Этот этап есть неотъемлемая часть процесса разработки. Если "переписывания" не происходит - то идет процесс накапливания болячек и "исторически сложившихся фактов". Рефакторингу подвергаются (и должны подвергаться) модули, с сохранением функционала.

Нельзя учесть все. Даже у автомобилей есть "детские болезни". Так что если Профсегмент занимается только латанием дыр, и добавлением функционала, получается большой залатанный дуршлаг, вместо кастрюли... Моя ИМХА... (Ну и так еще пары человек)

 

Вы пришли сразу на ПС3, как я понял. А я осуществлял переход с ПС2 на ПС3 и не понаслышке знаю каков это был труд. Мне пришлось переписать всю базу заново. В условиях работающего предприятия это не тривиальная задачка, уверяю Вас. Так вот я знаю, что такой сложный переход это не прихоть разработчика, а как раз настоятельная необходимость внесения определенных изменений и улучшений в программу. Только вот эти изменения и улучшения оказались слабо совместимы с тем, что было раньше.

Да - это есть переход на новое поколение программы. Сложности такой перехода обычная практика у многих разработчиков. Здесь-то как раз у меня вопросов и не возникло бы. Будь у меня 5-ти летняя база двойки и пришлось бы переходить на тройку. Да не вопрос... а вот проблемы простого обновления - это уже не кошерно (например история с реиндексайией проектов при потере связей с накладными С.Г.П.).

 

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

Опять же есть вот какой момент: FB сторонняя программа. Конечно в ней наверно поддерживается преемственность от версии к версии. Но может разработчики ПС решили использовать ее только как хранилище, что бы не зависеть от возможных изменений в ней, не быть заложниками возможных изменений не контролируемых ими? (Это не более, чем мое предположение, но и оно наверно имеет право на существование.)

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

 

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

Я никого не отговариваю, Боже упаси! Если быть честным - у программы большой потенциал. Но есть нюансы. Вам они не мешают (Потому, что у вас опыт работы с ПС), или не заменты (Потому, что вы этим не пользуетесь, или используете по другому). А мне пришлось три раза базу создавать с нуля, потому что в Профсегменте не было готового алгоритма действий для моей системы ПВХ.

 

Применительно к общению с разработчиками из ПрофСегмента я с уверенностью могу констатировать простой факт: тот кому нужен контакт и работа - тот все получит и найдет понимание. Знаю это на своем опыте, многолетнем. Не подводили меня ребята из ПрофСегмента. Не без проблем все было, но тем не менее.

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

[Wovan2]

А знаете. По-моему все еще не совсем плохо.

В принципе можно кое-какие манипуляции с БД произвести.

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

Жаль, что у меня пока не на чем проверить.

[MOHTEP]

А знаете. По-моему все еще не совсем плохо.

В принципе можно кое-какие манипуляции с БД произвести.

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

Жаль, что у меня пока не на чем проверить.

А какой смысл?

[Wovan2]

А какой смысл?

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

Edited January 28, 2009 by Wovan2

[MOHTEP]

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

Честно? Попробуй ... я только за - будет результат выкладывай скрипты... (или по почте)

[Wovan2]

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

[Ivga]

Очень любознательно было ознакомиться с темой.

Заблудшая на наше производство проггерская душа уже несколько раз пыталась рассказать всем (включая руководство) про обалдевший от индексов сервер. В преддверии перехода с 3-ки на 4-ку (а этот вопрос решенный, ибо продукт Профсегмента считаем достойным) вызывает интерес: есть ли решение данного вопроса в 4-ке?

Руководство-то, даже не пытается понять, про какие индексы речь, но напрягается, что что-то не так.

[dvim]

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

Там основные задержки имхо - вообще, не в сервере.

Кстати, кто-нибудь смог профайлер firebird прикрутить под пс3/профокна. Я не смог ....

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