Консолидация нескольких баз данных

[Iskatel]

Здравствуйте!

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

Вопрос такой:
Как осуществляется консолидация в единую базу данных из нескольких баз данных?

Пример: имеется 3 (может быть и больше) самостоятельно работающие базы Navision в разных городах
и есть необходимость сливать данные из всех трех и видеть в одной базе Navision, расположенной в головном офисе. Дело не в том, чтобы видеть только проводки, а в том, чтобы всю аналитику.

[Tzap]

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

[Fichy_imported]

Мы для этой цели разрабатывали функционал, передающий сводные обороты по счетам, учитывая при этом все возникающие комбинации измерений. Данные передаются/загружаются в формате XML.
Для целей формирования отчетности в сводной базе этого оказалось достаточно.
Единственный пока минус - не передается корреспонденция счетов, но необходимость этого определяется принципами построения отчетности в сводной базе.

[RedFox]

Цитата:

Сообщение от Programmer

Возник следующий вопрос:
Как осуществляется консолидация в единую базу данных из нескольких баз данных?

Пример: имеется 3 самостоятельно работающие базы Navision в разных городах и есть необходимость сливать данные из всех трех и видеть в одной базе Navision, расположенной в головном офисе. дело не в том, чтобы видеть только проводки, а в том, чтобы всю аналитику.

Буду рад услышать коментарии и идеи. Вообще это можно будет осуществить?

На нейтив-базе нужно либо реализовывать механизм переноса самостоятельно (например через C/FRONT), либо взять готовое (себе бы например, если ставил себе, то взял бы готовый функционал переноса (ДД) от розницы за 5 тонн евро+ 500 за каждый виртуальный "магазин", настроил и не морочил бы себе 5 точку).
Если SQL-базы, то переносы у них тоже не плохо работают.... даже вроде архивируются для передачи по сети.

[mazzy]

Цитата:

Сообщение от Programmer

Возник следующий вопрос:
Как осуществляется консолидация в единую базу данных из нескольких баз данных?

На уровне финансовых проводок. Через файл.

Цитата:

Сообщение от Programmer

Пример: имеется 3 самостоятельно работающие базы Navision в разных городах
и есть необходимость сливать данные из всех трех и видеть в одной базе Navision,
расположенной в головном офисе. дело не в том,
чтобы видеть только проводки, а в том, чтобы всю аналитику.

Если вам необходимо ВИДЕТЬ, то сделайте бэкап в одном городе и восстановите в отдельной компании в другом городе.
http://navision.mazzy.ru/lib/backup/


Но наверняка вам нужно не ВИДЕТЬ, а РАБОТАТЬ с аналитикой.
Например, делать заказы на складе другого города.

Разработчики сознательно не стали реализовывать функционал репликации в Навижине.
Потому что огранизовать канал дешевле, чем разгребать конфликты репликации.

Так, например,
ЕСЛИ на складе в Городе А есть 10 штук дефицитного товара
И продавец из Города Б заказывает 6 штук
И продавец из Города В заказывает 7 штук,
ТО в базах Города Б и В транзакция завершится
НО после репликации одна из них должна быть отклонена.

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

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

[mazzy]

Цитата:

Сообщение от Tzap

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

Не надо. Навижин ничего не знает о DTS.
Попытка "попробовать использовать DTS" в Навижин сравнима с закатом солнца вручную.

Цитата:

Сообщение от Fichy

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

Ужас нах.
В Навижине есть стандартный функционал для передачи финансовых данны.
Читайте про межфирменный учет.

Вот если бы вы сказали "мы ... ДОРАБАТЫВАЛИ ...", то было бы интересно.

[dmites]

Цитата:

Сообщение от mazzy

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

Разгребли - работаем теперь без проблем. )) - 42 удаленных базы с репликацией в сводную.
Проблем с заказами нет - 3 головастых парня в центре решают кому какой товар нужен
Проблем с одновременной правкой одних и тех же документов решается системой статусов
однако будем централизоваться, тем более что одновременный учет разрулили...

[mazzy]

Цитата:

Сообщение от dmites

Разгребли - работаем теперь без проблем. )) - 42 удаленных базы с репликацией в сводную.

Я и не спорю, что это можно сделать. )

Могу ли я спросить, сколько времени у вас заняла реализация и разгребание?

[dmites]

А я и не спорю, что не быстро ))
По образу и подобию той, что за 5 тонн евро, а вернее на её основе отвязали Cfront, привязали stream в/из файла + winrar + ftp +
таблиц разбить по диапазонам, в общем как говорится "мы делаем быстро, качественно, дешево" - выберите любые 2 пункта
...., но сейчас тьфу, тьфу всё пучком

[mazzy]

Цитата:

Сообщение от dmites

привязали stream в/из файла + winrar + ftp +
таблиц разбить по диапазонам

Подождите! Это же только транспортный уровень. Он делается очень быстро.
А конфликты репликации как обрабатываете?

[dmites]

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

[mazzy]

Цитата:

Сообщение от dmites

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

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

[dmites]

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

[dmites]

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

[Fichy_imported]

Цитата:

Сообщение от mazzy

В Навижине есть стандартный функционал для передачи финансовых данны.
Читайте про межфирменный учет.
Вот если бы вы сказали "мы ... ДОРАБАТЫВАЛИ ...", то было бы интересно.

Не соглашусь с Вами.

1. Разрабатывали под 3.7, где межфирменного учета нет
2. В условиях когда:
- данные нужны только для построения бухгалтерской (регламентной) отчетности, деклараций;
- кол-во учтенных документов в "дочерних" базах, ну скажем, миллион в год.
- кол-во дочерних баз - несколько десятков
передавать все транзакции в "родительскую" фирму просто избыточно.

[mazzy]

Цитата:

Сообщение от dmites

решающих многомерную траспортную задачу методом...

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

А остальные конфликты как вы решаете?
Дубли клиенов/поставщиков/номенклатуры, одновременная правка клиентов/поставщиков/номенклатуры...
Могу ли клиенты одного города заказывать в другом? Сохраняется ли история/скидки клиента в этом случае?

Цитата:

Сообщение от Fichy

1. Разрабатывали под 3.7, где межфирменного учета нет

Там была консолидация, если память мне не изменяет

[dmites]

идем тем же путем - как и в политике вертикаль власти ) -в Центре заводятся все справочники и реплицируются на магазины, где их править не могут.
Могу ли клиенты одного города заказывать в другом?
Могут, но через центр ..) всё через кремль..

[mazzy]

Цитата:

Сообщение от dmites

Могут, но через центр ..) всё через кремль..

вот такие ограничения
зато можно говорить, что сделали репликацию.

А можно спрочить?
Как вы считаете, с учетом имеющегося у вас опыта, было бы лучше/эффективнее/дешевле организовать каналы доступа к централизованной базе данных?

[RedFox]

Цитата:

Сообщение от mazzy

А можно спрочить?
Как вы считаете, с учетом имеющегося у вас опыта, было бы лучше/эффективнее/дешевле организовать каналы доступа к централизованной базе данных?

а можно подрезюмировать малеха, а не распыляться???

[mazzy]

Цитата:

Сообщение от RedFox

а можно подрезюмировать малеха, а не распыляться???

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

Однако есть случаи, когда таки программируют как консолидацию финансовых данных, так и репликацию.

При программировании репликации возникает масса ограничений.
Время и стоимость программирования репликации мы еще не выяснили.

Затраты на каналы и оборудование можно легко и быстро узнать для каждого региона.

По-моему, так.