Страница 1 из 2

9.1 PostgreSQL как решить проблему ведения множества юр лиц?

Добавлено: 11 июл 2012, 23:12
ecasoft
Мы как партнеры десяток лет ставили автоматизацию множества юр лиц, которые работают на одинаковых справочниках (МЦ, каталоги налогов, организации и т.д. всего штук 15-20) на базе механизка SяHEМА (пути в разных БД указывают на одни файлы, так они становятся общими для разных БД) на Первасиве, а также делали корпоративную отчетность и интерфейсы просмотра документов разных баз данных и их прямого копирования между базами а-ля Нортан и все на механизме OpenTableByPath (позволяет открыть динамически под разными синонимами одну таблицу разных БД).
Как всем известно Галактика закрывает Первасив в 9.1, а с ним и эту всю описанную выше функциональность (файлов в PostgreSQL нет, а есть единая БД и таблицы не распределишь, OpenTableByPath не понятно что означает и его убрали).

Мы сейчас оказались в очень сложном положении,т.к. альтернативы для ведения корпорации (PostgreSQL) в Галактике не стало.

Единственный очень дорогой (примерно повторная закупка + удвоение сопровождение) и очень сложный )нужно все наработанное за десяток лет переписать на механизм филиальности (не уверены что и получется как у нас было - другая идея) при переходе на Ms SQL. Филиальности на PostgreSQL нет (нет такого в Прайсе).

Хотелось бы найти тех, кто попал в аналогичную ситуацию. А также опыт по использованию филиальности. Спасибо.
P S Пока начали с клиентами продумывать переход на 1С, как самый понятный (по реализации) и реальный (по цене для клиента) выход. Не в восторге, но выхода сами не видим.

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Добавлено: 12 июл 2012, 10:12
edward_K
На MsSql тоже есть возможность делать общими справочники, сам не деалал, но слышал.
Что же касается филиальности, то это с одной стороны требует четкого понимания какие справочники будут общие, какие нет, но с
другой стороны можно будет получать отчеты по всем филиалам сразу(при наличии прав разумеется).

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Добавлено: 12 июл 2012, 12:55
LaaLaa
Технически на PostgreSQL "Филиальность" реализована и фактически работает. Но пока не тестировалась в большом объеме.
До "Филиальности" на MS SQL и Oracle было решение "Enterprise" но его дано уже перестали внедрять.

Для формирования сводного отчета по нескольким БД можете попробовать использовать подключение ADO в FastReport.

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Добавлено: 12 июл 2012, 13:03
LaaLaa
Как вариант синхронизировать справочники межу разными БД можно с помощью Корпо обмена.

Кроме того синхронизацию отдельных таблиц можно запрограммировать средствами смой СУБД на PL/pgSQL.

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Добавлено: 13 июл 2012, 14:42
ecasoft
Всем спасибо за комменты!

Хорошая новость о тестировании филиальности на рассматриемой базе - будем ждать. Надеемся также, что и ценовая политика на филиальность будет разумная (сейчас при 13 небольших фирмах в корпорации цена на MS SQL переваливает 10000 $), т.к. если до этого никто вообще не платил за лицензии по филиальности ничего на Первасиве, то предложить ему такие суммы просто за лицензии, да + сопровождение будет плохой идеей :sad:

К сожалению, нет решения для кода, который был написал на ВИПе и который смотрел все БД. Там интерфейсы. Да и отчеты сводные получается нужно переписывать полностью, если использовать FASTREPORT и доступом к разным базам. Кто это все захочет оплачивать - непонятно. Новых приладных свойств это не добавит, а скорее сократит - как объяснить руководству предприятий ЗА ЧТО ОНИ БУДУТ ПЛАТИТЬ?

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

Никто получается не использовал копроративность на Первасиве?

P S Жаль, что новшества приведут к неминуемой потере клиентов. Видимо у Галактике слишком много клиетов, что она их так просто вышвыривает.

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Добавлено: 14 июл 2012, 04:10
LaaLaa
На Первасиве филиальности не было. Ее технически не возможно было там сделать.

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

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Добавлено: 14 июл 2012, 13:41
m0p3e
ecasoft
Используем филиальность. Если правильно понял задачу, то она удовлетворит заказчика. Но база будет одна и распологаться она будет физически в одном месте, со всеми отсюда вытекающими...
Есть второй вариант - использование dsql. Я в опыте выкладывал как получать доступ к внешним данным, в том числе и из других баз, в том числе и с других серверов. Остается только продумать универсальную процедуру для эмуляции OpenTableByPath. Плюсы очевидны - не требуются дополнительные отчисления корпорации и работать будет однозначно быстрее.

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Добавлено: 16 июл 2012, 18:45
spark
LaaLaa писал(а):Технически на PostgreSQL "Филиальность" реализована и фактически работает. Но пока не тестировалась в большом объеме.
До "Филиальности" на MS SQL и Oracle было решение "Enterprise" но его дано уже перестали внедрять.

Для формирования сводного отчета по нескольким БД можете попробовать использовать подключение ADO в FastReport.
"Enterprise" когда-нибудь тоже внезапно прикроют? раз уж перестали внедрять...
А у нас он используется... А есть какой-нибудь механизм перехода с "Enterprise" на филиальность?

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Добавлено: 16 июл 2012, 18:50
LaaLaa
spark писал(а):"Enterprise" когда-нибудь тоже внезапно прикроют? раз уж перестали внедрять...
А у нас он используется... А есть какой-нибудь механизм перехода с "Enterprise" на филиальность?
Может быть техподожерка имеет опыт в этом. Попробуйте вопрос там задать.

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Добавлено: 17 июл 2012, 13:27
ecasoft
m0p3e писал(а):ecasoft
Используем филиальность. Если правильно понял задачу, то она удовлетворит заказчика. Но база будет одна и распологаться она будет физически в одном месте, со всеми отсюда вытекающими...
Есть второй вариант - использование dsql. Я в опыте выкладывал как получать доступ к внешним данным, в том числе и из других баз, в том числе и с других серверов. Остается только продумать универсальную процедуру для эмуляции OpenTableByPath. Плюсы очевидны - не требуются дополнительные отчисления корпорации и рабо втать будет однозначно быстрее.

Вы видимо на MS SQL, т.к. филиальности на рассматриваемой БД нет. На Ms Sql наши клиенты не хотят, а на PostgreSQL ее нет в Прайсе даже. Вот появилась информация, что будет вроде. До осени будет ждать. Для одно клиента это нормально, если не считать, что придется переписать код, который нарабатывался лет 5-6. Большой вопрос финансовый тут.

Для другого клиента одна БД для нескольких фирм не подходит. Тоже много кода.

Вопрос в принципе в чем. Мы разговаривали с разработчиками двайвера и ВИпа в Галактике (Москва). Они сказали, что считалось, что функция opentablebypath не используется сейчас никем. В принипе, после разпышлений с ними мы пришли к выводу, есть решение в виде эмуляции этой функуции, как средства доступа в различных БД из ВИПа для получения сводных отчетов можно найти. Главная проблема - включить эту разработку в план (она не включена). А чтобы включить нужно наличие некоторого количества клиентов. Вот я тут решил провентилировать, насколько нужна вообще всем копроратичность в Галактике и данное решение в частности. Если наберем группу, то возможно реализация в Галактике такого функционала.

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Добавлено: 17 июл 2012, 14:20
ecasoft
LaaLaa писал(а):На Первасиве филиальности не было. Ее технически не возможно было там сделать.

Упомянутый вами способ переключения путей отдельных таблиц, это давно забытый рудимент древних технологий.
Описанный механизм был поставлен внедренцами из ТОП-Софт в ЮКОСе в конце 90-х. Именно в ЮКОСе я впервые и уведел его, когда работал с этой компанией позже по договору. У нас все клиенты - корпорации из большого число ЮЛ и еще филиалов с общими таблицами. Этот функционал отлично подходил для реализации ведения деятельности в рамках корпорации. Сначало сделали для одной фирмы, а когда показывали других, то другие брали с удовольствием. И так было более 10 лет.
Понятно, что Первасив файловая система, а тут БД. И может механизм и устаревший, но другого нет.
Филиальности, как сами Вы знаете на платформе нет. Что делать клиентам? Они не видят этих функций (не знаю устаревгие они или нет)- они видят прикладные решения, которые хотят увидеть и платят деньги десятки лет, а каждый год ездят на конференции и так говорят, что у них Галактика работает хорошо.
Теперь давайте скажем, что функции устарели...клиентам скажем, что Галактика в том виде, как Вы ее эксплуатировали больше не будет работать, а за то, как мы вам сделает года через три Вы будете платить в два раза больше. Может пойти по пути создания аналогичного современного механизма доступа к различным БД по аналогии с устаревшими? Эмуляция этих функций?

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Добавлено: 18 июл 2012, 06:35
Алексей
здесь поддержу ecasoft
Галактика давно на рынке. Идет давняя борьба с 1С за "мелких" клиентов, в которой Галактика пока проигрывает. и такие казусы как отказ от поддержки функциональности которая была раньше и на которой работают много клиентов резко будет бить по имиджу компании.

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Добавлено: 18 июл 2012, 11:23
Dmitry_Sol
Я тоже пользовался функцией opentablebypath , на двух успешных и работающих проектах. Если не будет ее эмуляции, то придется ее делать самому. Жалко что пока нет такого же простого механизма, как shemealias на платформах отличных от первасива. Этот механизм у меня в четырех организациях внедрен.
Если по opentablebyPath есть номер пир, сообщите его, чтоб мы Минскую поддержку тоже пошевелили. Хочется к концу года перейти на 9.1. Но и переделывать все самим не хотелось бы.

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Добавлено: 18 июл 2012, 12:49
spark
Dmitry_Sol писал(а): Жалко что пока нет такого же простого механизма, как shemealias на платформах отличных от первасива.
Ну в принципе функционал Enterprise, который работает на оракле и сиквеле, по сути таже самая shemealias.

Re: 9.1 PostgreSQL как решить проблему ведения множества юр

Добавлено: 18 июл 2012, 13:17
KATZ
Алексей писал(а):Галактика давно на рынке. Идет давняя борьба с 1С за "мелких" клиентов, в которой Галактика пока проигрывает. и такие казусы как отказ от поддержки функциональности которая была раньше и на которой работают много клиентов резко будет бить по имиджу компании.
Да уже минимум лет 10 никакой борьбы нет. На 1000 пользователей с 1С один с "Галактикой", где здесь борьба-то?
ecasoft писал(а):Мы разговаривали с разработчиками двайвера и ВИпа в Галактике (Москва). Они сказали, что считалось, что функция opentablebypath не используется сейчас никем. В принипе, после разпышлений с ними мы пришли к выводу, есть решение в виде эмуляции этой функуции, как средства доступа в различных БД из ВИПа для получения сводных отчетов можно найти. Главная проблема - включить эту разработку в план (она не включена). А чтобы включить нужно наличие некоторого количества клиентов. Вот я тут решил провентилировать, насколько нужна вообще всем копроратичность в Галактике и данное решение в частности.
Мне тоже приходилось OpenTableByPath когда-то использовать. Клиент имел энное количество юр. лиц, все вели учет по единым правилам, но каждое - в своей БД, и было написано несколько специфических отчетов, консолидирующих данные по всем ЮЛ.
ecasoft писал(а):Если наберем группу, то возможно реализация в Галактике такого функционала.
Может, вам легче и быстрее будет собрать группу противников отказа от Первазива?

А хотите еще один вариант, получше? Вы с "Галактикой" давно работаете, ВИП у вас наверняка куплен и пара грамотных программистов найдется. Сейчас заключать договоры на АО и обновляться пользователи вынуждены по одной-единственной причине - из-за изменений законодательства. "Непрерывно наращиваемый функционал", о котором так любят говорить разработчики, 99,9% пользователей нахрен не нужен, у них уже всё устоялось, а с каждым обновлением только новые глюки добавляются. Откажитесь от обновлений из корпорации и поправляйте "Галактику" сами, только лишь в объеме, минимально необходимом для поддержки изменений в законодательстве. Сначала на своих клиентах это дело отладите, а потом кинете клич по всей Руси великой, стоимость установите вместо 3% в месяц, допустим, 1%, и 8 из 10 нынешних пользователей "Галактики" с радостью уйдут из корпорации и от ее партнеров к вам.