gardenman andycat wiland6/ 30-40 несложных отчетов (1-2 селекта)


наивные... :)
Вас одни расчеты резервов и отчеты в РСА так напрягут что мало не покажеться...


100% прав.

авторP.S. По практике: рекомендую одну центральную БД

Центральное хранилище в качестве DSS, с оптимизированной для отчетов структуктурой - согласен. Но вот все запихивать в одну систему - это просто никчему.

автор(выбрать с учетом роста минимум на 5лет с увеличеним клиентской БД) и в каждом СО свою. Механизм репликации OFF-Line и обязательно не на уровне БД а на уровне или отдельного программного модуля или сервера приложения.

Примерно так. Только называть это репликацией - неправильно.
По мне так вообще договора страхования необходимо хратить в XML.
Во всяком случае многие их текстовые части. (Это разумеется не касается ОСАГО)

Блин, ну что за страсть, понаставить отдельные базы в каждую деревню?
А синхронизация справочников (коих в страховании - немеряно, и почти все - реал-тайм изменяемые)? Ко всему прочему - и пополняются они не централизовано, а по факту возникновения события (ибо никто не будет ждать, пока бумага доедет до ЦО, а потом вернется через OFF-Line репликацию).
А админ к каждой такой базе? А железо для каждой базы?

И все это для чего? Для экномии на канале к центральной БД? Или еще для чего?

Dimitry Sibiryakov
Николай1
А синхронизация справочников (коих в страховании - немеряно, и почти все
- реал-тайм изменяемые)?

Ух ты! Реал-тайм изменяемые справочники, причём еще и пополняемые не
там, где используются! Пример можно?
Posted via ActualForum NNTP Server 1.4

Гм. Страховая компания.

Не очень понял, что значит "изменяемые не там, где используются"?
Я имел в виду другое - когда появляется несколько баз, то встает трудный выбор в определении того, где информация "самая правильная". И, как не сложно предположить, выбор делается в пользу базы в голове. Теперь предлагается домашнее задание - рассказть мне, как информация из деревни должна попасть в головную базу.

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

gardenman автор
И все это для чего? Для экномии на канале к центральной БД? Или еще для чего?
Ты не поверишь)) но даже не в деревне, а в ПИТЕРЕ три года назад далеко не самая последняя компания оказалась на филиалы тянуть сеть или подрубать всех на выделенки. А что говорить о деревнях?... Тут в руководство все упирается.

Не поверю.
А сравнить затраты на канал и на распределенную (OFF-Line) базу не пробовали?

Dimitry Sibiryakov
Николай1
А синхронизация справочников (коих в страховании - немеряно, и почти все
- реал-тайм изменяемые)?

Ух ты! Реал-тайм изменяемые справочники, причём еще и пополняемые не
там, где используются! Пример можно?
Posted via ActualForum NNTP Server 1.4

Что касается "реал-тайм", то имелось в виду следующее.
Есть справочники постоянные, например КЛАДР, который выпускается раз в год и потом не меняется. (примерно) С ними проблем нет.
Есть сильно распределенные, например - контрагенты. Понятно, что Иван Иванович, заведенный сегодня в питере, врядли понадобится кому-то сегодня же в Костроме. (но, вместе с тем, не факт, особенно если это не Иван Иванович, а, например, Роснефть).
А есть "реал-тайм", например - марки машин, по которым расчитывается страховая премия. И, если уж появилась новая марка или тариф на нее, то она должна быть "везде и сразу и одинаковая". А появиться она может где угодно, где ее первую захотят застраховать. (и не надо мне говорить, что "должны быть всегда все марки", это процесс, а не момент).

Вот, примерно так.

Dimitry Sibiryakov
Николай1
Не очень понял, что значит "изменяемые не там, где используются"?

Как один и тот же клиент может прйти в два филиала сразу, чтобы
создать дубликат информации в справочнике - тоже.

Если этот клиент - Роснефть, то Вы не поверите, он может прийти во все филиалы сразу!

Dimitry Sibiryakov
Николай1
она должна быть "везде и сразу и одинаковая". А появиться она может где
угодно, где ее первую захотят застраховать.

Ну так и off-line пакеты репликации, они тоже не конными курьерами
доставляются. Пересылка их электронной почтой три раза в день...
А застраховать новую марку машины могут только там, докуда добралась
сама машина. А машины тоже отнюдь не телепортом пользуются - обычные
автовозы и самовывоз, скорость до 200 км/ч. Так что пока новая
"Лада-малина" доедет из Самары в Москву, запись в справочнике еще и
поспать в БД-приёмнике успеет.
Posted via ActualForum NNTP Server 1.4

Речь шла не о машине, а о марке машины. Марки должны быть одинаковыми.
Может поискать тут топики про ввод номенклатуры. Про "Аленки", "Аленки-сливочные" и "Аленки-крем-брюле". Тут такая же петрушка. (она же "зелень").

Николай Кальмарский Dimitry SibiryakovОбъясните мне, туповатому!

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

Не столько задвоения, тут как раз особых проблем нет. А создания дубликатов, когда одно и тоже в разных местах названо по-разному.