Народ, покритикуйте идею интеграции

[imir]

Цитата:

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

Всё это вы хотите сделать только для построения сводной отчётности?

Сводная отчетность - оперативная и не очень, хранилище нормативно-справочной информации и заодно - место ее ввода. Ввод доп. информации из других систем для целей той же отчетности.

Допустим - если делать просто ХД, типа база на сиквеле:

1) Для ввода попутной информации в ХД - нужен интерфейс - инструмент или процедуры - какой продукт бы это обеспечил я не знаю - на просмотр-то понятно - смотреть можно чем угодно

2) Для ведения нормативно-справочной инфы - то же самое - либо покупать дорогущие продукты, либо задействовать одну из баз филиала, что скорее всего и придется - просто Акса-Хд это тоже может

3) Для просто ХД - надо заново разрабатывать структуру таблиц, состав полей, индексов - брать тупо Аксаптовскую - не логично

4) Импорт в ХД - надо писать - в Аксапте хотя бы есть AIF, адаптеры, пакетники, очереди и прочие радости.

Вобщем наличие интерфейса - сильный плюс в защиту Аксы-хранилища.

[blokva]

Бр-р-р-р не хотел бы я такого монстра сопровождать!
А как с НСИ? У Вас ведение справочников будет централизованное? Если да, то тогда репликации надо делать на филиалы, если нет, то опять же туда-сюда репликации. Если Выговорите связь плохая, провайдер один и прочая... то как будет обеспечиваться передача экспортных данных?
И вообще какое количество первичных документов в день по всей сети филиалов? С учетом сторно, кредит-нот? До какого размера у вас разрастется база и как быстро? На большой базе Акса вам ну очень долго будет клепать отчеты в "стандартном интерфейсе", а если несколько пользователей запустят несколько отчетов одновременно....

Я думаю Вам надо строго ограничить конечный результат, а сейчас такое ощущение, что Вам заказчик сказал что-то типа "хочу чтобы все было под рукой" и Вы ищите решение 1:1, но ВСЕ=НИЧЕГО. А если вы ограничите конечную задачу перечнем необходимой информации для анализа, то исходя из этого построите ОЛАП отчетность и будете наполнять кубы только минимально-необходимой информацией из филиалов. А это и резкое снижение объемов импорта-экспорта и снижение нагрузки на центральный сервер и на группу сопровождения. И у Вас останется куча времени на решение проблем с репликацией НСИ - от этого никуда не денешься!

[imir]

Цитата:

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

А как с НСИ? У Вас ведение справочников будет централизованное?
И вообще какое количество первичных документов в день по всей сети филиалов?До какого размера у вас разрастется база и как быстро?
На большой базе Акса вам ну очень долго будет клепать отчеты в "стандартном интерфейсе"

Вы ищите решение 1:1, но ВСЕ=НИЧЕГО.

НСИ - реально предполагается звезда - т.е. важные справочники заводятся в центре и разлетаются - синхронизация двусторонняя - из центра НСИ, в центр - факт.

Объемы приличные, это да. Я думаю центральная база 200гб в год вполне реально. Ну на то оно и ХД - таблицы можно партиционировать, секционировать раскидывать по файловым группам и т.д. Учитываем, что синхронизации подлежат не все таблицы и не все поля при желании. В основном - таблицы документов и проводок и только нужные поля - только чтобы Аксе хватило для навигации и отображения.

По поводу скорсти да - структура базы останется OLTP, о этого никуда не денешься, а вот нужных индексов для анализа наклепать никто не запрещает.
Я уже прикинул, что допустим, InventDim будет не оптимальным - т.е. умноженным в 10 раз, а если грузить документы - мог бы быть чуть меньше - раз 5 - все равно коды складов уникальны - т.е. еще большее уменьшение мало вероятно. Но это самый тяжелый пример, осталные таблицы по размеру будут идентичны работе всех филиалов в одной базе.

[ziva]

Цитата:

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

Исходная задача стоит так ....

У меня было подобное решение с работающим прототипом в логистическом контуре.
Вкратце (для знатоков 1С - прослеживается прямая аналогия с УРБД ):
Каждая инсталляция имеет свой диапазон RecId.
Все используемые таблицы разделяются на три типа:
1) master - суть документы/операции (LedgerJournalTable, SalesTable, ...). Их вводит пользователь на каждой из инсталляций Ах. Весьма подходят таблицы с TableGroup = WorksheetHeader
2) slave (строки документов, порожденные мастером записи - документы и проводки - LedgerJournalTrans, SalesLine, CustInvoiceJour, CustInvoiceTrans, MarkupTrans, LedgerTrans ….). Весьма подходят таблицы с TableGroup = WorksheetLine, Transaction
3) setup - настроечные (параметры модулей, группы, и прочее). Весьма подходят таблицы с TableGroup = Miscellaneous, Parameter, Group, Main.

Итак, приложения должны на всех инсталляциях быть идентичными.
Таблицы с типом ‘setup’ идут только из центра по всем периферийным инсталляциям. Никаких изменений их на периферии. Таким образом получаем централизованное управление настройками и правами.

Остальное может "гулять" в соответствии с настроенными правилами – каждая периф.инсталляция имеет свой диапазон значений RecId (по RecId master записи всегда можно понять откуда свалился документ). По мере выполнения транзакций в инсталляциях ведётся лог тех записей которые были изменены (например был создан, изменен, и разнесен SalesTable) – из него выцепляются master-записи, и уже потом определяются те slave которые нужно с ними тянуть. Дальше транспорт решает куда этот пакет данных девать и как. Кроме того, чтобы были целостные inventSum и прочие, по сути возникает log shipping – ненарушаемая последовательность документов которые необходимо вставить из одной инсталляции в другую (например для неотрицательно физ склада закупка должна прийти раньше чем заказ). Но это уже опционально

Конечно возникает ряд вопросов – например с сопоставлением, закрытием склада. Но они решаемые при должном административном ресурсе и определенном количестве серого вещества.

Прототип где-то пылится - разработка велась года 4 назад. Там была Ах3 и соответственно диапазонов RecId не хватало чтобы сделать масштабное решение. Кроме того не было возможности повесить триггер на изменение (создание\удаление) любой записи - приходилось выкручиваться средствами БД. В АХ2009й проблемы с диапазоном RecId и перехватыванием событий нет – так что решение вполне жизнеспособно.

Примерный срок реализации такого решения - 3-4 месяца (*2 чела), с учётом того что есть безглючный транспорт (.NET Remoting).

Вообщем вот вам ещё один вариант реализации этой задачи. Остальное сами додумывайте.