ValerikНарод вот такая вот вещь
Допустим у нас есть какое то производство, на котором ведется учет (эта часть в принципе легко реализуема)


Твоими бы устами, да мед кушать

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


Какая вся? Если совсем вся, то можно просто делать полную одностороннюю
репликацию баз регионов в главный офис. Средствами нормальных СУБД
делается элементарно.

Valerik
Т.е. все проходило быстро, надежно, практично. В регионах тоже идет деление на мелкие магазины, т.е. здесь тоже нужно организовать передачу данных в региональный офис.

Аналогично предыдущему
Valerik
Чего нужно достичь:
1. Нужно что бы в любом магазине можно было посмотреть сколько иметься того или оного товара на складе в региональном офисе - это нужно дл оптовиков.
2. Тоже самое и для региональных офисов, что бы можно было посмотреть, сколько товара на главном складе..

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

Будет ли такой метод безопасным? И реализуем л он вообще? Какие могут быть проблемы?

Проблема номер Ноль: упал канал - все встали. А стоимость канала
с надежностью 99,999 весьма высока. Если в Москве еще можно себе
позволить резервные каналы, то в регионах с этим могут быть проблемы.
Valerik
И что бы вы посоветовали ?
Интересно услышать мнение людей имеющих похожий опыт
А что тут советовать? Я бы сказал, классическая схема. Каждый офис,
представительство, магазин - отдельный центр учета со своей собственной БД, способной работать автономно.
Рисуются схемы потоков необходимых данных между этими центрами.
С учетом этого проектируются базы и настраивается репликация между
ними.

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

--
http://talk.ru/forum/talk.ru.accounting.development

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

И сисопа с модератором в каждый магазин
Не пугай серьезных людей словом ФИДО ;)
А если серьезно, то из первоначального постинга можно сделать предположение, что наличие инета предполагается. А в этом случае лучше
полагаться на более "классические" транспорты: FTP, e-mail и т.п.
IgorTv
Система транспортировки должна решать проблемы подтверждения отправки\получения, неповторной отправки или не повторного получения и т.д.

Работать обе системы должны независимо друг от друга. Когда количество магазинов привысит 10-15 нужно будет устраивать ночные автоматические процедуры дозвона\отправки\разноски и т.д.

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

Короче интересная задача :)

Интересная, как и любое изобретение велосипеда с нуля.
Это называется словом "репликация" и для этого существую инструменты, решающие процитированные задачи.