|
|
|
Синхронизация данных между двумя ИС
|
|||
|---|---|---|---|
|
#18+
iscrafmРеалистМожет быть потенциальный конфликт, даже при "зеркальной" синхронизации, когда от загружаемых данных зависит другая выполненная работа. В этом случае ее нужно будет удалять, раз данные, на основе которых эта работа выполнена, будут загружены по новой. если "работа" выполняется на основании каких-то данных и этих данных нет в базе на определенный момент времени, то как бы и "работы" нет. Или речь о другом идет? дык нет данных физически, а "логически" они есть. и чс ним работа уже описана в другой системе. далее данные вводят снова, но с другим уникальным идентификатором .. куда работу девать? не удалять жен, иначе придется и и в другой системе повторно все вводить. Вот дял атких сиутация мы используем - семантическую привязку, т.е. идентификация идет не на основе первичного ключа, а на основе семантики сущности. Такое возможно для многих сущностей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2010, 05:05 |
|
||
|
Синхронизация данных между двумя ИС
|
|||
|---|---|---|---|
|
#18+
Mainframe_старыйiscrafmРеалистМожет быть потенциальный конфликт, даже при "зеркальной" синхронизации, когда от загружаемых данных зависит другая выполненная работа. В этом случае ее нужно будет удалять, раз данные, на основе которых эта работа выполнена, будут загружены по новой. если "работа" выполняется на основании каких-то данных и этих данных нет в базе на определенный момент времени, то как бы и "работы" нет. Или речь о другом идет? дык нет данных физически, а "логически" они есть. и чс ним работа уже описана в другой системе. далее данные вводят снова, но с другим уникальным идентификатором .. куда работу девать? не удалять жен, иначе придется и и в другой системе повторно все вводить. Вот дял атких сиутация мы используем - семантическую привязку, т.е. идентификация идет не на основе первичного ключа, а на основе семантики сущности. Такое возможно для многих сущностей. На основании чего Вы так решили? Данные есть физически. Они загружены из системы ИС1, "работа" выполнена правомерно и ни физическая, ни логическая целостность системы ИС2 не нарушена . Работа с данными описана в той же системе, что и сами данные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2010, 10:51 |
|
||
|
Синхронизация данных между двумя ИС
|
|||
|---|---|---|---|
|
#18+
> мы используем - семантическую привязку Для внешних источников imho удобно поддерживать промежуточную базу данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2010, 11:07 |
|
||
|
Синхронизация данных между двумя ИС
|
|||
|---|---|---|---|
|
#18+
guest_20040621> мы используем - семантическую привязку Какая бы это была привязка, например для казначейского платежа так чтобы ключ связи был уникальным? На мой взгляд даже максимальная комбинация полей платежного поручения не гарантирует уникальности платежа, т.е. придется принять что двух платежей с одинаковыми реквизитами не бывает. guest_20040621 Для внешних источников imho удобно поддерживать промежуточную базу данных. Правильно я понял, что Вы предлагаете добавить ИС0 которая будет назначать идетификаторы платежам, а потом из нее мы грузим независимо в ИС1 и ИС2? Если так, то какая гарантия, что с ИС0 не случится сбой/восстановление? В итоге придем к началу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2010, 17:44 |
|
||
|
Синхронизация данных между двумя ИС
|
|||
|---|---|---|---|
|
#18+
egorych[Уже понятно, что контроля над кодом ИС1 у вас нет, однако: администрирование этой системы находится в ваших руках? есть ли возможность развернуть тестовую версию этой системы? Администрирование можно управлять только посредством корректировки регламентов, потому как кол-во пар ИС1-ИС2 более 80 (регионы) Тестовую версию ИС1 конечно можно развернуть, только вопрос что это дает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2010, 17:46 |
|
||
|
Синхронизация данных между двумя ИС
|
|||
|---|---|---|---|
|
#18+
iscrafmRus000iscrafmRus000, речь идет о системах, над которыми Вы не имеете контроля? т.е. это закрытое ПО, чьего-то производства? ИС1 разработана другим исполнителем и доступна только как источник данных, изменять код ИС1 не представляется возможным в краткосрочной перспективе понятно. Тогда в ИС2 придется напрямую получать первичную информацию из казначейства. Если конечно есть такая возможность. да, такой вариант возможен но придется серьезно переписывать блок приема платежей, а это время и ресурсы. Пока рассматриваю его как наиболее правильно но крайний вариант ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2010, 17:51 |
|
||
|
Синхронизация данных между двумя ИС
|
|||
|---|---|---|---|
|
#18+
> добавить ИС0 Да. > какая гарантия, что с ИС0 не случится сбой/восстановление? Никакой. Фишка в том, что вы можете поддерживать заданную доступность и актуальность данных. Причем, можете архитектурно отвязать их от внутренних данных, выбрав, например, линейно масштабируемое решение для промежуточной базы данных, не переписывая всех приложений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.07.2010, 18:26 |
|
||
|
Синхронизация данных между двумя ИС
|
|||
|---|---|---|---|
|
#18+
guest_20040621> добавить ИС0 Да. > какая гарантия, что с ИС0 не случится сбой/восстановление? Никакой. Фишка в том, что вы можете поддерживать заданную доступность и актуальность данных. Причем, можете архитектурно отвязать их от внутренних данных, выбрав, например, линейно масштабируемое решение для промежуточной базы данных, не переписывая всех приложений. это да, но ведь все равно нужно принять каким-то образом, что объект А (из ИС1) с первичным ключем I, это тот же самый, что раньше был D с первичным ключем J. И принимать это или в переходной (канонической= ИС0) схеме или уже в ИС2. (Канонические схемы полезны, конечно). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2010, 02:53 |
|
||
|
Синхронизация данных между двумя ИС
|
|||
|---|---|---|---|
|
#18+
Rus000 Какая бы это была привязка, например для казначейского платежа так чтобы ключ связи был уникальным? На мой взгляд даже максимальная комбинация полей платежного поручения не гарантирует уникальности платежа, т.е. придется принять что двух платежей с одинаковыми реквизитами не бывает. Это не для всех сущностей проходит, но для многих. Например, студентов мы гоняем.. не по первичному ключу,а по паспорту+дата рождения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2010, 03:02 |
|
||
|
Синхронизация данных между двумя ИС
|
|||
|---|---|---|---|
|
#18+
Mainframe_старыйRus000 Какая бы это была привязка, например для казначейского платежа так чтобы ключ связи был уникальным? На мой взгляд даже максимальная комбинация полей платежного поручения не гарантирует уникальности платежа, т.е. придется принять что двух платежей с одинаковыми реквизитами не бывает. Это не для всех сущностей проходит, но для многих. Например, студентов мы гоняем.. не по первичному ключу,а по паспорту+дата рождения. в моей практике например встречались полные двойники с совпадающими ФИО, датой рождения и местом рождения, так чта .... тут надо осторожнее ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2010, 07:30 |
|
||
|
Синхронизация данных между двумя ИС
|
|||
|---|---|---|---|
|
#18+
> все равно нужно принять каким-то образом, что объект А (из ИС1) с первичным ключем I, это тот же самый, что раньше был D с первичным ключем J Идентификаторы для внешних данных будут раздаваться в ИС0 и будут одинаковыми для всех ИС(1,2,3... n). Можно держать любое количество экземпляров ИС0, кроме того, можно еще и разбить ИС0 на оперативную и архивные таким образом, чтобы связать их с политикой бэкапа основных ИС, минимизировав количество данных в ИС0 и ускорив ее восстановление после сбоя. Бонус промежуточной ИС еще и в том, что в ней можно вести полноценную историю изменений (любые другие процедуры, синхронные с основными политиками основных ИС), - вряд ли эту проблему решают внешние источники. Для примера с казначейством это не актуально, но можно придумать кучу других (в частности, с персональными данными), когда это будет полезным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.07.2010, 09:09 |
|
||
|
|
start [/forum/topic.php?fid=33&gotonew=1&tid=1548251]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
54ms |
get topic data: |
11ms |
get first new msg: |
8ms |
get forum data: |
3ms |
get page messages: |
56ms |
get tp. blocked users: |
2ms |
| others: | 312ms |
| total: | 477ms |
| 0 / 0 |
