|
|
|
Обновление справочника из нескольких мест...
|
|||
|---|---|---|---|
|
#18+
Добрый день! Просьба навести критику и предложить лучше :) Есть распределённая система (несколько БД с синхронизацией). Реально один справочник могут править несколько операторов одновременно. Например- два оператора добавляют один и тот же новый дом. Потом всё это приезжает на одну "главную" БД, где некоторый ответственный разгребает мусор. И видит он два дома номер 13. Причём к каждому уже привязано куча всего в не очень известных местах. Как это можно сделать правильно? Пока идея хранить в таблице (Id, TrueId, Values...) Например создали до 13 под ID 1023 и 1024. (1023, 1023, 13, ...) (1024, 1024, 13, ...) Начальник посмотрел и поправил. Теперь стало (1023, 1023, 13, ...) (1024, 1023, 13, ...) К выбору предлагаются (и показываются обычно) те записи, у кого TrueId=Id. Если мы ищем запись, то переходим по TrueId. Тогда в справочник всем будут видна только одна запись, а бегать по всей системе и менять 1024 на 1023 не надо. -- Алексей JID: alxt@ya.ru Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2009, 16:07:36 |
|
||
|
Обновление справочника из нескольких мест...
|
|||
|---|---|---|---|
|
#18+
Корректировка справочников (в моём понимании) происходит сравнительно редко. И кроме того, важные справочники можно вынести в главную БД. Если происходит такая ситуация, что два оператора в РАЗНЫХ БД правят один и тот-же географический объект, то скорее всего архитектура системы имеет изъяны. Надо устранить этот недостаток и всё будет ОК. А в рамках одно базы несогласнованные корректировки пресекаются транзакциями с блокировкой FOR UPDATE. Впрочем, здесь надо смотреть, какую вы используете RDBMS и отталкиваться от её возможностей. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 13:04:53 |
|
||
|
Обновление справочника из нескольких мест...
|
|||
|---|---|---|---|
|
#18+
GKS_SamaraЕсть распределённая система (несколько БД с синхронизацией). Реально один справочник могут править несколько операторов одновременно.Делали такое... У нас код словарной статьи состоит из двух частей "код оператора и код слова в словаре". Когда оператор добавляет новое слово, оно создается в словаре с кодом типа "петя0034". Главный офис соответственно регулярно проверяет словарь и вычищает его от персонализированных записей. Запись либо теряет префикс оператора и становится глобальной (просто update словаря, а дальше работает триггер на внешние ключи), либо все таблицы ссылающиеся на этот словарь получают команду типа "update t set dic1='34565' where dic1='петя0034'" а лишняя запись в словаре убивается. Все изменения уходят в филиалы в следующий сеанс репликации как обычно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 20:20:27 |
|
||
|
Обновление справочника из нескольких мест...
|
|||
|---|---|---|---|
|
#18+
GKS_SamaraПотом всё это приезжает на одну "главную" БД, где некоторый ответственный разгребает мусор. И видит он два дома номер 13. Наиболее нормально таки не допускать мусора. Для чего есть простой вариант: вместо "добавляют дом" операторы добавляют "задание на создание дома". Это задание реплицируется в главную БД и исполняется там, результаты реплицируются по офисам. Как правило справочники модифицируются не настолько часто, чтобы "подождать пять минут пока запись съездит туда-сюда" стало проблемой. Ваш подход имхо хорош для разгребания, но потребует от программиста дополнительных усилий в каждом запросе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.12.2009, 21:09:40 |
|
||
|
Обновление справочника из нескольких мест...
|
|||
|---|---|---|---|
|
#18+
softwarer Наиболее нормально таки не допускать мусора. Для чего есть простой вариант: вместо "добавляют дом" операторы добавляют "задание на создание дома". Это задание реплицируется в главную БД и исполняется там, результаты реплицируются по офисам. Как правило справочники модифицируются не настолько часто, чтобы "подождать пять минут пока запись съездит туда-сюда" стало проблемой. Эта мысль была. Проблема вот в чём. Построили новый дом. Приходят два человека из этого дома и хотят стать клиентами. Операторы независимо делают (неважно как) два новых объекта "дом" с номер 13. Хуже то, что нет единой БД- модули максимально независимы, общаются через JMS. И если люди придут к операторам разных модулей? Вводить информацию централизованно нельзя, т.к. дом по документам может ещё отсутствовать :) Отсылать запрос в центральный модуль адресов это хорошо, но всё одно этот модуль должен обладать некоторым интеллектом- у того же дома есть поле "комментарий" и разные операторы могут туда написать разный текст. И что с этим делать? Ещё одно требование к архитектуре- если главный модуль отвалился, то остальные должны продолжать работать. Тоже противоречит идеи "всё через одно место" :) Хотя можно сказать, что адреса в это время заводить нельзя... softwarer Ваш подход имхо хорош для разгребания, но потребует от программиста дополнительных усилий в каждом запросе. Да, требует. Любая функциональность требует. -- Алексей JID: alxt@ya.ru Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2009, 07:42:38 |
|
||
|
Обновление справочника из нескольких мест...
|
|||
|---|---|---|---|
|
#18+
White Owl Запись либо теряет префикс оператора и становится глобальной (просто update словаря, а дальше работает триггер на внешние ключи), либо все таблицы ссылающиеся на этот словарь получают команду типа "update t set dic1='34565' where dic1='петя0034'" а лишняя запись в словаре убивается. Все изменения уходят в филиалы в следующий сеанс репликации как обычно. Нет, update невозможен по причине присутствия кучи старого кода, от которого местами даже исходники потерялись. -- Алексей JID: alxt@ya.ru Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2009, 07:43:59 |
|
||
|
Обновление справочника из нескольких мест...
|
|||
|---|---|---|---|
|
#18+
GKS_SamaraОператоры независимо делают (неважно как) два новых объекта "дом" с номер 13. Операторы независимо делают задания. И пока оператор вводит прочую информацию по клиенту, это задание вполне успеет съездить в центральную БД и вернуться с ID дома - добавленным или найденным. GKS_SamaraИ если люди придут к операторам разных модулей? Никакой разницы. Главное - есть единое информационное пространство. И разумное время репликации в этом пространстве. Если их нет - тогда, конечно, только разгребать мусор. GKS_Samaraу того же дома есть поле "комментарий" и разные операторы могут туда написать разный текст. И что с этим делать? (пожимая плечами) Да что угодно. Я бы постарался подрезать права рядовых операторов на ввод данных в центральные справочники, но в принципе как поставите задачу - так и можно реализовать. GKS_SamaraХотя можно сказать, что адреса в это время заводить нельзя... Можно. Мне кажется, тут нужно просто оценить стоимость вариантов - задержки на несколько минут в довольно редком случае ввода нового дома и перманентных трат на поддержку "мусорной" схемы. GKS_SamaraДа, требует. Любая функциональность требует. Не совсем так. Хорошая функциональность требует усилий один раз - сделал и наслаждаешься. Плохая - требует постоянных усилий: помнить о ней, учитывать её потребности... Подозреваю, 2/3 ваших модулей будут так или иначе работать с адресами. Вот теперь представьте, сколько дополнительного тестирования потребуется, чтобы убедиться, что везде в них работа организована правильно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2009, 08:42:30 |
|
||
|
Обновление справочника из нескольких мест...
|
|||
|---|---|---|---|
|
#18+
softwarer GKS_Samara у того же дома есть поле "комментарий" и разные операторы могут туда написать разный текст. И что с этим делать? (пожимая плечами) Да что угодно. Я бы постарался подрезать права рядовых операторов на ввод данных в центральные справочники, но в принципе как поставите задачу - так и можно реализовать. Это хорошо, но не всегда реализуемо... softwarer GKS_Samara Хотя можно сказать, что адреса в это время заводить нельзя... Можно. Мне кажется, тут нужно просто оценить стоимость вариантов - задержки на несколько минут в довольно редком случае ввода нового дома и перманентных трат на поддержку "мусорной" схемы. Проблема в том, что операторы тупы по-определению, и могут творить что угодно. "Противодураковая защита от идиотов не работает". Так что мусорные записи могут создаваться в любом случае. И даже уникальный индекс на "улица+номер_дома+корпус" не спасёт от творческого идиота. softwarer Не совсем так. Хорошая функциональность требует усилий один раз - сделал и наслаждаешься. Плохая - требует постоянных усилий: помнить о ней, учитывать её потребности... Подозреваю, 2/3 ваших модулей будут так или иначе работать с адресами. Вот теперь представьте, сколько дополнительного тестирования потребуется, чтобы убедиться, что везде в них работа организована правильно. Аргумент. Спасибо, буду думать дальше... -- Алексей JID: alxt@ya.ru Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2009, 08:48:36 |
|
||
|
Обновление справочника из нескольких мест...
|
|||
|---|---|---|---|
|
#18+
Интеграция по справочникам, управление мастер данными — это фундамент для связи разнородных систем или модулей. Поэтому лучше поднажать, еще приложить усилия и сделать эту часть очень толково. Немного о этой проблеме писалось на integration-review.com . Если у вас модули уже асинхронно связаны через JMS, тогда сделать осталось совсем немного. Исходя из своего скромного опыта (интеграция 10+ приложений в крупной конторе), я бы сделал так (с учетом создания, и возможности обновления справочников): 1. Сделал ввод элементов любых справочников централизованным. Т.е. если связи с центром нету, вводить их не положено. 2. В клиентском модуле реализовал простенький интерфейс для добавления нового элемента справочника или редактирования существующего. Ввел новый элемент, подправил существующий — задание в виде JMS-сообщения уехало в центр. При этом у задания может быть несколько Verb-ов: Create, Update. Т.е. это была всего лишь "просьба" . 3. Это сообщение, равно как и от всех остальных модулей, обрабатывает "центр". Он создает новую запись и рассылает всем клиентам также асинхронно, в виде JMS-сообщений. Важно, центр присваивает _код_ созданному элементу. В дальнейшем по этому коду будет проходить обновление. Вот от центра уже приходит "поручение" , обязательное к выполнению всеми модулями. У поручения также должен быть Verb: Create, Update. 4. Только после того, как клиент (даже тот, через который проходило создание этого элемента) получит новый элемент справочника, создаст его у себя, он может с ним работать. В штатном режиме это будет фунциклировать на ура. Задержки будут не заметны. Дублей не получится, потому как созданное другими пользователями будет оперативно доставляться на клиенты. Если со связью с центром будут проблемы, тогда сообщения из центра приедут как только она поднимется, а до того момента создавать справочники из клиента будет невозможно. Такой вариант мне кажется наиболее целостным и изящным . У нас же, справочники вводятся вообще сугубо централизованно, в ERP. Есть пользователи от разных отделов, бизнесов, которые вводят новые элементы, редактируют их. Это снимает огромную головную боль, которая как вирус может расползтись по всем системам или модулям. Кстати, еще один вариант — не громоздить интерфейс создания и редактирования внутри каждого модуля, а сделать простенький web-интерфейс для ввода справочников. Задания на создание и обновление рассылать, как я и писал с 3-го пункта. Асинхронность берет в жертвы простоту реализации. Но если сделать изначально грамотно, все останутся довольный. Сорри, если сумбурно или не понятно. Возможно я не уловил контекст вопроса. pi/\gr ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2009, 10:34:07 |
|
||
|
Обновление справочника из нескольких мест...
|
|||
|---|---|---|---|
|
#18+
pilgr Сорри, если сумбурно или не понятно. Возможно я не уловил контекст вопроса. Да нет, всё понятно. И мы тоже потихоньку пришли примерно к тому же. Спасибо :) -- Алексей JID: alxt@ya.ru Posted via ActualForum NNTP Server 1.4 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2009, 10:48:16 |
|
||
|
Обновление справочника из нескольких мест...
|
|||
|---|---|---|---|
|
#18+
ТО, что вы говорите у микрософта уже давно есть и называется REST автор 1. Сделал ввод элементов любых справочников централизованным. Т.е. если связи с центром нету, вводить их не положено. 2. В клиентском модуле реализовал простенький интерфейс для добавления нового элемента справочника или редактирования существующего. Ввел новый элемент, подправил существующий — задание в виде JMS-сообщения уехало в центр. При этом у задания может быть несколько Verb-ов: Create, Update. Т.е. это была всего лишь "просьба". ... Микрософтовцы разрулили подобную ситуацию так - если связи нет сохряняется у тебя на компе. Потом идет на сервак. Самое интересное в этой всей беде - репликация. как понять что строки от васи важнее строк от пети? в REST это рулится на основе определенных правил с учетом времени обновления и чего то там еще. не помню. Идею можно посмотреть в ролике на techdays.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2009, 12:46:23 |
|
||
|
Обновление справочника из нескольких мест...
|
|||
|---|---|---|---|
|
#18+
MCTSТО, что вы говорите у микрософта уже давно есть и называется REST Это у всех давно есть. Хорошо, если и микрософт наконец сподобился свистнуть нормальное решение. MCTSСамое интересное в этой всей беде - репликация. как понять что строки от васи важнее строк от пети? Ноль интереса. Понимать так же, как это понимают Петя и Вася, если один из них ввёл информацию на день, месяц или год раньше. "Кто первый встал, того и тапки", а второй может, если хочет и имеет право, потом отредактировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2009, 13:06:59 |
|
||
|
|

start [/forum/topic.php?fid=16&msg=36376883&tid=1344006]: |
0ms |
get settings: |
9ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
188ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
50ms |
get tp. blocked users: |
1ms |
| others: | 206ms |
| total: | 488ms |

| 0 / 0 |
