Померяемся?
Померяемся?
Вопрос. У кого больше ?? Если есть, поделитесь опытом "прекрасной работы" приложения
- Вкладення
-
- medoc333333.jpg (50.16 Кіб) Переглянуто 11370 разів
-
- Повідомлень: 330
- З нами з: 22 серпня 2011, 09:28
- Звідки: Харьковская обл.
- Контактна інформація:
Re: Померяемся?
а приложение причем? не понятно.
Re: Померяемся?
А что тут не понятного?? Количество документов в базе пропорционально скорости работы программы, чем больше документов тем больше "тормоза"
-
- Повідомлень: 8802
- З нами з: 29 липня 2011, 14:59
- Звідки: Украина, Донецкая область, Бахмут
- Контактна інформація:
Re: Померяемся?
А у Вас сеть на ФБ?
зы: рекордсмены работают на оракле, думаю тормозов у них нет.
зы: рекордсмены работают на оракле, думаю тормозов у них нет.
Re: Померяемся?
да ФБ, а разве у Oracle (той версии что использует медок) нет ограничения на размер БД ?
И чем не устраивает ФБ? Он отлично работает с большим объемом БД
http://www.ib-aid.com/articles/1-tb-fir ... ry-report/
И чем не устраивает ФБ? Он отлично работает с большим объемом БД
http://www.ib-aid.com/articles/1-tb-fir ... ry-report/
Хотелось бы услышать самих рекордсменов, думаю не все так гладкоКолпаков Б.И. писав: зы: рекордсмены работают на оракле, думаю тормозов у них нет.
-
- Повідомлень: 8802
- З нами з: 29 липня 2011, 14:59
- Звідки: Украина, Донецкая область, Бахмут
- Контактна інформація:
Re: Померяемся?
У рекордсменов - мобильных операторов, Укртелеком, РЭС, ГГ десятки тысяч в день записей!
http://database-management.softwareinsi ... -vs-Oracle
Больше проблем с DMF.AppServer.exe
По сути устраивает всем, плюс Мед без особого труда можно заставить работать на последней версии ФБ.Ktoia писав:да ФБ, а разве у Oracle (той версии что использует медок) нет ограничения на размер БД ? И чем не устраивает ФБ?
http://database-management.softwareinsi ... -vs-Oracle
Больше проблем с DMF.AppServer.exe
Re: Померяемся?
Теперь я не пойму, какой можно сделать вывод ? Есть ли смысл переходить на oracle!? Если "да" то почему ? Есть ли ограничения в работе с БД на oracle (например количество ядер ЦПУ, объемом ОЗУ, Максимальным размером БД)Колпаков Б.И. писав:У рекордсменов - мобильных операторов, Укртелеком, РЭС, ГГ десятки тысяч в день записей!
По сути устраивает всем, плюс Мед без особого труда можно заставить работать на последней версии ФБ.Ktoia писав:да ФБ, а разве у Oracle (той версии что использует медок) нет ограничения на размер БД ? И чем не устраивает ФБ?
http://database-management.softwareinsi ... -vs-Oracle
Больше проблем с DMF.AppServer.exe
Re: Померяемся?
оракл летает по сравнению с Фаербердом, около 100 тысяч в месяц документовКолпаков Б.И. писав:А у Вас сеть на ФБ?
зы: рекордсмены работают на оракле, думаю тормозов у них нет.
Re: Померяемся?
Это хорошая новость, а как обстоит дело с размером БД ? Я о том что БД на ФБ растет очень сильно. Есть ли такая проблема на Oracle, если "да" то как бороться ?Festy30 писав:оракл летает по сравнению с Фаербердом, около 100 тысяч в месяц документовКолпаков Б.И. писав:А у Вас сеть на ФБ?
зы: рекордсмены работают на оракле, думаю тормозов у них нет.
Re: Померяемся?
С этим боротся не приходится, поставили винт на 320 гигов и нет проблем, дальше чтобы база не росла архивируем НН.
Re: Померяемся?
Festy30 , спасибо большое за ответ.
В работе с модулем "архивирование документов" я столкнулся со следующими проблемами:
1) Архивируется не только документы которые помечены в ручную на архивирование но и документы которые по какой-то своей логике помечаются медком как «архивные».
2) Выбрать период, за который необходимо провести архивацию документов не возможно, т.е. архивируются все документы по текущую дату.
3) Выполнение архивации каждый раз проходит по всем документам предыдущих месяцев, что приводит к очень долгому выполнению данной операции на моей довольно скромной базе порядка 2-х суток. (Хотя это возможно связано с тем что у меня FB, а не Oracle)
А как у Вас обстоит дело с работой данного модуля ?
Но вот тут то как раз и начинается самое интересное.Festy30 писав:архивируем НН.
В работе с модулем "архивирование документов" я столкнулся со следующими проблемами:
1) Архивируется не только документы которые помечены в ручную на архивирование но и документы которые по какой-то своей логике помечаются медком как «архивные».
2) Выбрать период, за который необходимо провести архивацию документов не возможно, т.е. архивируются все документы по текущую дату.
3) Выполнение архивации каждый раз проходит по всем документам предыдущих месяцев, что приводит к очень долгому выполнению данной операции на моей довольно скромной базе порядка 2-х суток. (Хотя это возможно связано с тем что у меня FB, а не Oracle)
А как у Вас обстоит дело с работой данного модуля ?
Re: Померяемся?
Насчет работы СУДБ Firebird, в моей компании сейчас стоит вопрос перехода на СУДБ Oracle, из за медленной работы программы MEDOC. Размер базы 210 гб. сетевая версия. Небольшое предисловие, в компании где я работаю большое количество баз на СУБД Firebird, около 40 баз, включая базу центрального офиса, документооборот в разы превышает медка, и база быстро работает. Реши с разработчиком посмотреть где же собственно затык, тестировали на отображении документов в форме (реестр первичных документов) выбирали различные месяца, итоги следующие, запрос на базе отрабатывает 3с. потом ожидание около минуты, в лучшем случае, после отображаеться список документов. Вопрос что так долго делает сервер приложений, если база очень быстро отвечает на запросы? Виновата ли сама СУДБ? Декомпилировав библиотеку (ZvitServerDataFB) выяснили что она для подключения с СУДБ использует очень древнюю версию библиотеки (FirebirdSql.Data.FirebirdClient.dll) версия (2.5.1) актуальня 4.6.4 http://www.firebirdsql.org/en/additional-downloads/ , по опыту разработчиков у старой библиотеки есть ряд проблем, в частности когда используется режим FB Clasic она не закрывает старые конэкты. Писал на тех поддержку о этой проблеме, но ответ получил оригинальный (Данные проблемы могут быть напрямую связаны с проблемой работы службы на Win Server 2012, правки по которой выйдут в ближайшем тех.обновлении. Уточните, пожалуйста, пользователи выходят обычным способом, но процессы зависают в Мониторинге пользователей?).
P.S. Сервер приложений не единственное узкое место, если на базе в двух таблицах построить индексы, то скорость работы формы (реестр первичных документов)
выпростает на глазах, такое впечатление что базу делали студенты 3 курса....
таблицы: Полеля:
CARDJOURNALOPER FILETYPE
CARDUREAD2 IDORG,USR,OPERTYPE
CARD SENDSTT
RDCARD_HISTORY DOCDATE,ROUTE
REL_USER_ROLE_ORG IDUSER,IDORG
Судя по проведенным тестам проблема не в СУБД, а в сервере приложений, Oralce использует другой клиент в сервере приложений этим объясняется его быстродействие, ели разработчики допилсят сервер приложений то и на Firebird будет все ок))))))))
P.S. Сервер приложений не единственное узкое место, если на базе в двух таблицах построить индексы, то скорость работы формы (реестр первичных документов)
выпростает на глазах, такое впечатление что базу делали студенты 3 курса....
таблицы: Полеля:
CARDJOURNALOPER FILETYPE
CARDUREAD2 IDORG,USR,OPERTYPE
CARD SENDSTT
RDCARD_HISTORY DOCDATE,ROUTE
REL_USER_ROLE_ORG IDUSER,IDORG
Судя по проведенным тестам проблема не в СУБД, а в сервере приложений, Oralce использует другой клиент в сервере приложений этим объясняется его быстродействие, ели разработчики допилсят сервер приложений то и на Firebird будет все ок))))))))
Re: Померяемся?
Не , ну чё за страна, блин............
У них:
За зарплату в 4-6 тыс ГРН?????
Обратитесь непосредственно к разрабам по телефону(на сайте) , они проведут анализ и выставят Вам счёт на "ДОПИЛИВАНИЕ".
После оплаты они ВАМ допилят.......................
У них:
А им всё равно жалко денег на СУДБ Oracle:GreN писав:..... Размер базы 210 гб. сетевая версия. ................
За какие шиши програмёры разработчика будут "ДОПИЛИВАТЬ"?GreN писав:....... разработчики допилсят сервер приложений то и на Firebird будет все ок
За зарплату в 4-6 тыс ГРН?????
Обратитесь непосредственно к разрабам по телефону(на сайте) , они проведут анализ и выставят Вам счёт на "ДОПИЛИВАНИЕ".
После оплаты они ВАМ допилят.......................
https://www.youtube.com/watch?v=1Q54t3-3ZaE
ХутинПуйло!
ХутинПуйло!
Re: Померяемся?
Насколько я понимаю, Медок сейчас по максимуму отказывается от своих бесплатных функций. Становясь полностью коммерческим продуктом. И это нормально. При одном условии.Когда цена и качество идут в одной связке.Насколько я понимаю, столь разрекламированный продукт, и такой незаменимый, как об этом говорят дилеры и реклама на сайте, обязан быть современным. А современный, это не только цена соответствующая ожиданиям продавца. Современный, это соответствие ожиданиям покупателя. И если клиент дал себе труд разобраться в тараканах медока и указал на очевидные вещи, то как минимум это наглость, а как максимум хамство, высмеять его за это.
Программистов с зарплатой в 4-6 тысяч конечно жалко.Но вопросы качества продуктов и допиливания его до необходимого уровня, а не рисование никому не нужных рюшиков, это компетенция менеджмента. И если руководству плевать на качество Медока, никто ни за какие деньги его не будет "допиливать".Вопрос в отношении к клиентам. Они же и так его купят.Верно?
Зачем беспокоится и реагировать на жалобы клиентов, когда можно их просто послать... к разработчикам за индивидуальным решением проблемы.Прекрасно понимая, что вероятность такого решения в разы мала.
Неужели только крупные клиенты ( с большой базой документов) заинтересованы в быстродействии.Или, господа дилеры, Вы при продаже рассказываете клиентам правду, что их ждет при работе с Медоком.И клиенты покупают его с открытыми глазами.
Мои вопросы, скорее риторические. Потому что, сколько существует медок, столько и ведутся дискуссии о его быстродействии и соотношении цена- качество.Что обиднее всего, а воз и ныне там.Хотя, раньше было еще хуже.Медок выбрался из младенческих пеленок, но все еще в ползунках.Извините за образность, вечер наверное
Программистов с зарплатой в 4-6 тысяч конечно жалко.Но вопросы качества продуктов и допиливания его до необходимого уровня, а не рисование никому не нужных рюшиков, это компетенция менеджмента. И если руководству плевать на качество Медока, никто ни за какие деньги его не будет "допиливать".Вопрос в отношении к клиентам. Они же и так его купят.Верно?
Зачем беспокоится и реагировать на жалобы клиентов, когда можно их просто послать... к разработчикам за индивидуальным решением проблемы.Прекрасно понимая, что вероятность такого решения в разы мала.
Неужели только крупные клиенты ( с большой базой документов) заинтересованы в быстродействии.Или, господа дилеры, Вы при продаже рассказываете клиентам правду, что их ждет при работе с Медоком.И клиенты покупают его с открытыми глазами.
Мои вопросы, скорее риторические. Потому что, сколько существует медок, столько и ведутся дискуссии о его быстродействии и соотношении цена- качество.Что обиднее всего, а воз и ныне там.Хотя, раньше было еще хуже.Медок выбрался из младенческих пеленок, но все еще в ползунках.Извините за образность, вечер наверное
-
- Повідомлень: 330
- З нами з: 22 серпня 2011, 09:28
- Звідки: Харьковская обл.
- Контактна інформація:
Re: Померяемся?
а ведь человек не слабо так ковырнул в суть проблемы. Всё описал. Поделился на форуме. Прям выполнил чью-то работу. А его за это...... не нужно так.
Re: Померяемся?
А не верю я, что это клиент!abaddon89 писав:а ведь человек не слабо так ковырнул в суть проблемы. Всё описал. Поделился на форуме. Прям выполнил чью-то работу. А его за это.......
База 210 гБ, А ЗАРЕГИСТРИРОВАЛСЯ НА ФОРУМЕ - вчера!!!!
Да само содержание топика проявляет конкурента!!!!!
https://www.youtube.com/watch?v=1Q54t3-3ZaE
ХутинПуйло!
ХутинПуйло!
Re: Померяемся?
ага, это шпиен из "Интербейса"priup писав:А не верю я, что это клиент!abaddon89 писав:а ведь человек не слабо так ковырнул в суть проблемы. Всё описал. Поделился на форуме. Прям выполнил чью-то работу. А его за это.......
База 210 гБ, А ЗАРЕГИСТРИРОВАЛСЯ НА ФОРУМЕ - вчера!!!!
Да само содержание топика проявляет конкурента!!!!!
На этом месте должна была быть какая-то подпись
Re: Померяемся?
Уважаемый. Это проклятая Америка проплатила !!!priup писав:А не верю я, что это клиент!abaddon89 писав:а ведь человек не слабо так ковырнул в суть проблемы. Всё описал. Поделился на форуме. Прям выполнил чью-то работу. А его за это.......
База 210 гБ, А ЗАРЕГИСТРИРОВАЛСЯ НА ФОРУМЕ - вчера!!!!
Да само содержание топика проявляет конкурента!!!!!
Т.е. человек ОБЯЗАН быть зарегистрирован на форуме с первого дня покупки этого ПО ? Или тут человек пытается донести инфу, доступную широким массам для дескридитации этого СУПЕР СОВЕРШЕННОГО, ОТЛИЧНОГО продукта ? Спасибо лучше скажи за проделанный труд. Человек делает НЕ СВОЮ РАБОТУ, а работу сотредников этого МЕДКА.
Re: Померяемся?
И так по сути, есть большая база на Firebird, кто сказал что она должна работать медленно, скорее всего разработчики не слышали про оптимизацию баз, ниже привожу конкретные индексы, после построения которых форма о которой идет речь работает быстрее. Еще раз повторяю база работает быстро, проблема в прокладке между базой и конечным приложением.priup писав:Не , ну чё за страна, блин............
У них:А им всё равно жалко денег на СУДБ Oracle:GreN писав:..... Размер базы 210 гб. сетевая версия. ................За какие шиши програмёры разработчика будут "ДОПИЛИВАТЬ"?GreN писав:....... разработчики допилсят сервер приложений то и на Firebird будет все ок
За зарплату в 4-6 тыс ГРН?????
Обратитесь непосредственно к разрабам по телефону(на сайте) , они проведут анализ и выставят Вам счёт на "ДОПИЛИВАНИЕ".
После оплаты они ВАМ допилят.......................
Просто вдумайтесь, компания которая делает медок на своем офицальном сайте пишет что не поддерживает базы больше 100гб на Firebird, из за того что ему не хватает производительности. Но пофакту после тестов, база работает быстро, если еще допилить немного, начинает летать, но прокладка ввиде сервера приложений тупит, всесто решения проблеммы предлагает ще потратить денег на Oracle.....
CREATE INDEX CARDJOURNALOPER_FILETYPE_333 ON CARDJOURNALOPER (FILETYPE);
CREATE INDEX CARDUREAD2_IDX_3333 ON CARDUREAD2 (IDORG, USR, OPERTYPE);
CREATE INDEX CARD_SENDSTT_333333 ON CARD (SENDSTT);
CREATE INDEX RDCARD_HISTORY_DR_333 ON RDCARD_HISTORY (DOCDATE, ROUTE);
CREATE INDEX REL_USER_ROLE_ORG_USER_333 ON REL_USER_ROLE_ORG (IDUSER, IDORG);
--новый
CREATE OR ALTER VIEW CARDDOCUREAD(
DOCTYPE,
DOCID,
USR)
AS
select DOCTYPE, DOCID, USR from CARDUREAD2 group by DOCTYPE, DOCID, USR
;
--старый
CREATE OR ALTER VIEW CARDDOCUREAD_333(
DOCTYPE,
DOCID,
USR)
AS
select DISTINCT DOCTYPE, DOCID, USR from CARDUREAD2
;
За какие шиши програмёры разработчика будут "ДОПИЛИВАТЬ"?
моя компания тратит деньги на тех поддержку медка, вот за них и допилить.
Re: Померяемся?
И так по сути, есть большая база на Firebird, кто сказал что она должна работать медленно, скорее всего разработчики не слышали про оптимизацию баз, ниже привожу конкретные индексы, после построения которых форма о которой идет речь работает быстрее. Еще раз повторяю база работает быстро, проблема в прокладке между базой и конечным приложением.priup писав:Не , ну чё за страна, блин............
У них:А им всё равно жалко денег на СУДБ Oracle:GreN писав:..... Размер базы 210 гб. сетевая версия. ................За какие шиши програмёры разработчика будут "ДОПИЛИВАТЬ"?GreN писав:....... разработчики допилсят сервер приложений то и на Firebird будет все ок
За зарплату в 4-6 тыс ГРН?????
Обратитесь непосредственно к разрабам по телефону(на сайте) , они проведут анализ и выставят Вам счёт на "ДОПИЛИВАНИЕ".
После оплаты они ВАМ допилят.......................
Просто вдумайтесь, компания которая делает медок на своем офицальном сайте пишет что не поддерживает базы больше 100гб на Firebird, из за того что ему не хватает производительности. Но пофакту после тестов, база работает быстро, если еще допилить немного, начинает летать, но прокладка ввиде сервера приложений тупит, всесто решения проблеммы предлагает ще потратить денег на Oracle.....
CREATE INDEX CARDJOURNALOPER_FILETYPE_333 ON CARDJOURNALOPER (FILETYPE);
CREATE INDEX CARDUREAD2_IDX_3333 ON CARDUREAD2 (IDORG, USR, OPERTYPE);
CREATE INDEX CARD_SENDSTT_333333 ON CARD (SENDSTT);
CREATE INDEX RDCARD_HISTORY_DR_333 ON RDCARD_HISTORY (DOCDATE, ROUTE);
CREATE INDEX REL_USER_ROLE_ORG_USER_333 ON REL_USER_ROLE_ORG (IDUSER, IDORG);
--новый
CREATE OR ALTER VIEW CARDDOCUREAD(
DOCTYPE,
DOCID,
USR)
AS
select DOCTYPE, DOCID, USR from CARDUREAD2 group by DOCTYPE, DOCID, USR
;
--старый
CREATE OR ALTER VIEW CARDDOCUREAD_333(
DOCTYPE,
DOCID,
USR)
AS
select DISTINCT DOCTYPE, DOCID, USR from CARDUREAD2
;
За какие шиши програмёры разработчика будут "ДОПИЛИВАТЬ"?
моя компания тратит деньги на тех поддержку медка, вот за них и допилить.