powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Обновление справочника из нескольких мест...
13 сообщений из 13, страница 1 из 1
Обновление справочника из нескольких мест...
    #36374228
GKS_Samara
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Добрый день!

Просьба навести критику и предложить лучше :)

Есть распределённая система (несколько БД с синхронизацией).
Реально один справочник могут править несколько операторов одновременно.
Например- два оператора добавляют один и тот же новый дом.
Потом всё это приезжает на одну "главную" БД, где некоторый ответственный разгребает мусор.
И видит он два дома номер 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
...
Рейтинг: 0 / 0
Обновление справочника из нескольких мест...
    #36375235
Фотография mayton
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Корректировка справочников (в моём понимании) происходит сравнительно редко. И кроме того, важные справочники можно вынести в главную БД. Если происходит такая ситуация, что два оператора в РАЗНЫХ БД правят один и тот-же географический объект, то скорее всего архитектура системы имеет изъяны. Надо устранить этот недостаток и всё будет ОК. А в рамках одно базы несогласнованные корректировки пресекаются транзакциями с блокировкой FOR UPDATE. Впрочем, здесь надо смотреть, какую вы используете RDBMS и отталкиваться от её возможностей.
...
Рейтинг: 0 / 0
Обновление справочника из нескольких мест...
    #36375691
White Owl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GKS_SamaraЕсть распределённая система (несколько БД с синхронизацией).
Реально один справочник могут править несколько операторов одновременно.Делали такое...
У нас код словарной статьи состоит из двух частей "код оператора и код слова в словаре". Когда оператор добавляет новое слово, оно создается в словаре с кодом типа "петя0034".
Главный офис соответственно регулярно проверяет словарь и вычищает его от персонализированных записей. Запись либо теряет префикс оператора и становится глобальной (просто update словаря, а дальше работает триггер на внешние ключи), либо все таблицы ссылающиеся на этот словарь получают команду типа "update t set dic1='34565' where dic1='петя0034'" а лишняя запись в словаре убивается. Все изменения уходят в филиалы в следующий сеанс репликации как обычно.
...
Рейтинг: 0 / 0
Обновление справочника из нескольких мест...
    #36375769
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GKS_SamaraПотом всё это приезжает на одну "главную" БД, где некоторый ответственный разгребает мусор. И видит он два дома номер 13.
Наиболее нормально таки не допускать мусора. Для чего есть простой вариант: вместо "добавляют дом" операторы добавляют "задание на создание дома". Это задание реплицируется в главную БД и исполняется там, результаты реплицируются по офисам. Как правило справочники модифицируются не настолько часто, чтобы "подождать пять минут пока запись съездит туда-сюда" стало проблемой.

Ваш подход имхо хорош для разгребания, но потребует от программиста дополнительных усилий в каждом запросе.
...
Рейтинг: 0 / 0
Обновление справочника из нескольких мест...
    #36376881
GKS_Samara
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
Наиболее нормально таки не допускать мусора. Для чего есть простой
вариант: вместо "добавляют дом" операторы добавляют "задание на создание
дома". Это задание реплицируется в главную БД и исполняется там,
результаты реплицируются по офисам. Как правило справочники
модифицируются не настолько часто, чтобы "подождать пять минут пока
запись съездит туда-сюда" стало проблемой.


Эта мысль была.

Проблема вот в чём. Построили новый дом. Приходят два человека из этого дома и хотят стать клиентами.
Операторы независимо делают (неважно как) два новых объекта "дом" с номер 13.
Хуже то, что нет единой БД- модули максимально независимы, общаются через JMS.
И если люди придут к операторам разных модулей?
Вводить информацию централизованно нельзя, т.к. дом по документам может ещё отсутствовать :)

Отсылать запрос в центральный модуль адресов это хорошо, но всё одно этот модуль должен
обладать некоторым интеллектом- у того же дома есть поле "комментарий" и разные операторы могут туда
написать разный текст. И что с этим делать?

Ещё одно требование к архитектуре- если главный модуль отвалился, то остальные
должны продолжать работать. Тоже противоречит идеи "всё через одно место" :)
Хотя можно сказать, что адреса в это время заводить нельзя...

softwarer
Ваш подход имхо хорош для разгребания, но потребует от программиста
дополнительных усилий в каждом запросе.


Да, требует. Любая функциональность требует.

--
Алексей
JID: alxt@ya.ru
Posted
via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Обновление справочника из нескольких мест...
    #36376883
GKS_Samara
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
White Owl
Запись либо теряет префикс оператора и
становится глобальной (просто update словаря, а дальше работает триггер
на внешние ключи), либо все таблицы ссылающиеся на этот словарь получают
команду типа "update t set dic1='34565' where dic1='петя0034'" а лишняя
запись в словаре убивается. Все изменения уходят в филиалы в следующий
сеанс репликации как обычно.


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

--
Алексей
JID: alxt@ya.ru
Posted
via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Обновление справочника из нескольких мест...
    #36376911
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
GKS_SamaraОператоры независимо делают (неважно как) два новых объекта "дом" с номер 13.
Операторы независимо делают задания. И пока оператор вводит прочую информацию по клиенту, это задание вполне успеет съездить в центральную БД и вернуться с ID дома - добавленным или найденным.

GKS_SamaraИ если люди придут к операторам разных модулей?
Никакой разницы. Главное - есть единое информационное пространство. И разумное время репликации в этом пространстве. Если их нет - тогда, конечно, только разгребать мусор.

GKS_Samaraу того же дома есть поле "комментарий" и разные операторы могут туда
написать разный текст. И что с этим делать?
(пожимая плечами) Да что угодно. Я бы постарался подрезать права рядовых операторов на ввод данных в центральные справочники, но в принципе как поставите задачу - так и можно реализовать.

GKS_SamaraХотя можно сказать, что адреса в это время заводить нельзя...
Можно. Мне кажется, тут нужно просто оценить стоимость вариантов - задержки на несколько минут в довольно редком случае ввода нового дома и перманентных трат на поддержку "мусорной" схемы.

GKS_SamaraДа, требует. Любая функциональность требует.
Не совсем так. Хорошая функциональность требует усилий один раз - сделал и наслаждаешься. Плохая - требует постоянных усилий: помнить о ней, учитывать её потребности... Подозреваю, 2/3 ваших модулей будут так или иначе работать с адресами. Вот теперь представьте, сколько дополнительного тестирования потребуется, чтобы убедиться, что везде в них работа организована правильно.
...
Рейтинг: 0 / 0
Обновление справочника из нескольких мест...
    #36376914
GKS_Samara
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
GKS_Samara
у того же дома есть поле "комментарий" и разные операторы могут туда написать разный текст. И что с этим делать?

(пожимая плечами) Да что угодно. Я бы постарался подрезать права рядовых операторов на ввод данных в центральные
справочники, но в принципе как поставите задачу - так и можно реализовать.


Это хорошо, но не всегда реализуемо...

softwarer
GKS_Samara
Хотя можно сказать, что адреса в это время заводить нельзя...

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


Проблема в том, что операторы тупы по-определению, и могут творить что угодно.
"Противодураковая защита от идиотов не работает".
Так что мусорные записи могут создаваться в любом случае.
И даже уникальный индекс на "улица+номер_дома+корпус" не спасёт от творческого идиота.

softwarer
Не совсем так. Хорошая функциональность требует усилий один раз - сделал
и наслаждаешься. Плохая - требует постоянных усилий: помнить о ней,
учитывать её потребности... Подозреваю, 2/3 ваших модулей будут так или
иначе работать с адресами. Вот теперь представьте, сколько
дополнительного тестирования потребуется, чтобы убедиться, что везде в
них работа организована правильно.


Аргумент.
Спасибо, буду думать дальше...

--
Алексей
JID: alxt@ya.ru
Posted
via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Обновление справочника из нескольких мест...
    #36377052
Фотография pilgr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Интеграция по справочникам, управление мастер данными — это фундамент для связи разнородных систем или модулей. Поэтому лучше поднажать, еще приложить усилия и сделать эту часть очень толково.

Немного о этой проблеме писалось на integration-review.com .

Если у вас модули уже асинхронно связаны через JMS, тогда сделать осталось совсем немного.
Исходя из своего скромного опыта (интеграция 10+ приложений в крупной конторе), я бы сделал так (с учетом создания, и возможности обновления справочников):

1. Сделал ввод элементов любых справочников централизованным. Т.е. если связи с центром нету, вводить их не положено.

2. В клиентском модуле реализовал простенький интерфейс для добавления нового элемента справочника или редактирования существующего. Ввел новый элемент, подправил существующий — задание в виде JMS-сообщения уехало в центр. При этом у задания может быть несколько Verb-ов: Create, Update. Т.е. это была всего лишь "просьба" .

3. Это сообщение, равно как и от всех остальных модулей, обрабатывает "центр". Он создает новую запись и рассылает всем клиентам также асинхронно, в виде JMS-сообщений. Важно, центр присваивает _код_ созданному элементу. В дальнейшем по этому коду будет проходить обновление. Вот от центра уже приходит "поручение" , обязательное к выполнению всеми модулями. У поручения также должен быть Verb: Create, Update.

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

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

Такой вариант мне кажется наиболее целостным и изящным .

У нас же, справочники вводятся вообще сугубо централизованно, в ERP. Есть пользователи от разных отделов, бизнесов, которые вводят новые элементы, редактируют их. Это снимает огромную головную боль, которая как вирус может расползтись по всем системам или модулям. Кстати, еще один вариант — не громоздить интерфейс создания и редактирования внутри каждого модуля, а сделать простенький web-интерфейс для ввода справочников. Задания на создание и обновление рассылать, как я и писал с 3-го пункта.

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

Сорри, если сумбурно или не понятно. Возможно я не уловил контекст вопроса.

pi/\gr
...
Рейтинг: 0 / 0
Обновление справочника из нескольких мест...
    #36377072
GKS_Samara
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pilgr
Сорри, если сумбурно или не понятно. Возможно я не уловил контекст вопроса.


Да нет, всё понятно. И мы тоже потихоньку пришли примерно к тому же. Спасибо :)

--
Алексей
JID: alxt@ya.ru
Posted
via ActualForum NNTP Server 1.4
...
Рейтинг: 0 / 0
Обновление справочника из нескольких мест...
    #36377320
MCTS
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ТО, что вы говорите у микрософта уже давно есть и называется REST
автор
1. Сделал ввод элементов любых справочников централизованным. Т.е. если связи с центром нету, вводить их не положено.

2. В клиентском модуле реализовал простенький интерфейс для добавления нового элемента справочника или редактирования существующего. Ввел новый элемент, подправил существующий — задание в виде JMS-сообщения уехало в центр. При этом у задания может быть несколько Verb-ов: Create, Update. Т.е. это была всего лишь "просьба".
...


Микрософтовцы разрулили подобную ситуацию так - если связи нет сохряняется у тебя на компе. Потом идет на сервак. Самое интересное в этой всей беде - репликация. как понять что строки от васи важнее строк от пети? в REST это рулится на основе определенных правил с учетом времени обновления и чего то там еще. не помню. Идею можно посмотреть в ролике на techdays.ru
...
Рейтинг: 0 / 0
Обновление справочника из нескольких мест...
    #36377376
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MCTSТО, что вы говорите у микрософта уже давно есть и называется REST
Это у всех давно есть. Хорошо, если и микрософт наконец сподобился свистнуть нормальное решение.

MCTSСамое интересное в этой всей беде - репликация. как понять что строки от васи важнее строк от пети?
Ноль интереса. Понимать так же, как это понимают Петя и Вася, если один из них ввёл информацию на день, месяц или год раньше. "Кто первый встал, того и тапки", а второй может, если хочет и имеет право, потом отредактировать.
...
Рейтинг: 0 / 0
Обновление справочника из нескольких мест...
    #36381828
GYGY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
GKS_Samara,

По моему тут делается ХД, при загрузке данных в которые вычищаются все эти коллизии. Ну и отдельный человек для этого в принципе не так уж и нужен.
...
Рейтинг: 0 / 0
13 сообщений из 13, страница 1 из 1
Форумы / Программирование [игнор отключен] [закрыт для гостей] / Обновление справочника из нескольких мест...
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]