Перевод учета в из подчиненной базы в старшую : Супермаг Плюс (Супермаг 2000)

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

Плюсы:
-нет ошибок по сверке БД
-нет проблем в расхождении БД
-снижение затрат на дополнительное оборудование
-снижение затрат времени на администрирование

Минусы:
-сильная зависимость от стабильности канала связи.

Вопросы:
- кто то уже пробовал организовать работу по такому принципу, какие подводные камни есть?

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

И, соответственно, вопрос, зачем вы себе такое устроить хотите? Сейчас что не устраивает?

Кроме стабильности канала, есть ещё его ширина.
На всякий случай напомню что Супермаг это "толстый" клиент, а не web приложение.

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

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

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

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

Зачем.
1) Когда кол-во магазинов переваливает за 30 шт вопросы администрирования начинают занимать существенное кол-во времени. Если нужно распишу по пунктам тут ведь много проблем возникает (установить обновление, сверить базы, решить проблемы обмена в почтовом модуле, установить новый ценник).
2) Кол-во ошибок и расхождений между базами тоже увеличивается .
3) Финансовые затраты на открытие новой торговой точки. 1 новый магазин = 1 новый сервер.

1. А вы хотели, чтобы количество магазинов не влияло на количество возникающих сопутствующих вопросов? Не смешно же... Зато яйца в одной корзине будут... Бабахните обновлением базу - встанут все разом. Проблемы обмена возникают только из-за косяков операторов, либо плохой связи. Первому ничего не даст перевод в одну базу, второе будет мучить связистов и даст повод народу сачковать "потому, что связи не было" и причину для конфликтов.

2. Повторение первого пункта. Будут ошибки в центральной базе. Еще и друг на друга будут завязываться. Голову потом лечить будете разгребать это все в одной каше, а не последовательно.

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

К всему вышесказанному. Сейчас в базе офиса у вас работает человек 30. После перевода - под сотню.
Это разная нагрузка.
И для нее нужно и железо покруче, и хороший администратор баз данных.

Ты забыл ещё опытного ДБА, потому что кроме железа это всё ещё и администрировать надо будет, причем в режиме реального времени.
А то запустят какой-нибудь ТОЗЦ и ляжет всё.