DmitryKn

AndyNigmatec

Taran
И стоит ли их делить?

Полагаю такое "добро" уже досталось ТС, теперь ему что-то с этим делать ...

Одно досталось, второе, обучаясь, ваял сам, как понимал.

Так это всё упрощает.
Маленько пошел не тем путём. Надо было не новую программу писать, а имеющуюся доращивать. Ежели конечно она в исходниках доступна.

Вы сильно торопитесь с кодом. Сначала надо решить, что и зачем делать. Потом уже выбирать "как делать"

Проблема выглядит следующим образом

Существуют два независимых приложения со своими базами данных. Как следствие, свои справочники в каждом приложении. Однако пользователи ожидают, что если создали/изменили запись справочника в одном приложении, то это изменение должно отразится и в другом приложении.

Какие есть варианты решения проблемы. В принципе, все их уже озвучили, но если обобщить, то

1. Синхронизация
2. Одно место для хранения данных по справочникам

Это в самом общем виде. Каждый из этих вариантов имеет еще кучу своих вариантов решения

1. Синхронизация

В самом общем виде, это означает, что любые изменения в любом приложении автоматически копируются в другое приложение. Но для решения этой задачи должен существовать общий идентификатор записей. Одинаковый в обоих приложениях. Просто чтобы понимать какая запись новая, а какая - это изменение существующей записи

Теоретически, для контрагентов можно было бы использовать их УНП (ИНН в РФ), но практика показывает, что это не вполне надежное решение. Пользователь может не знать или могут оказаться одинаковые значения у разных записей.

Поэтому в таких случаях делают взаимную идентификацию. Т.е. в справочнике одного приложения делают ссылку на запись другого приложения (новое поле в таблице). Обновление этих ссылок в момент синхронизации. А первый раз эти ссылки следует проставить вручную.

Т.е. в приложении 1 в справочнике контрагентов указать код записи из приложения 2. И наоборот. В приложении 2 в справочнике контрагентов указать код записи из приложения 1

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

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

Такую синхронизацию можно делать "на лету" в момент изменения (триггера в DBC или просто дополнительный код там, где происходит сохранение изменений справочника). Или же сделать некую периодическую операцию, которая раз в 5 минут (полчаса, час, раз в день) делает такое сравнение и обновление. Разумеется, если такая задержка обновления допустима

"Подвариант" синхронизации - это в момент сохранения изменения в таблице делать запись в лог изменений. В каком приложении, в какой записи что изменили. А в процедуре синхронизации по этому логу делать соответствующие изменения в другом приложении. Лог - это дополнительный аргумент в случае каких-либо конфликтных ситуаций с пользователями.

С логом можно еще так поступить. При обращении к справочнику сначала смотреть на лог. Если там есть не обработанные записи (изменения в другом приложении), то выполнить обновление в текущем приложении. Т.е. при изменении в справочнике делаем запись в лог, а при чтении справочника - сначала выполняем обновление из лога. Если оформить этот самый лог как свободную таблицу, то отпадает необходимость обращения к базам данных другого приложения

В общем, разные варианты есть...

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


2. Одно место для хранения данных по справочникам

Ну, это как раз то, что Вам "интуитивно понятно". Но и здесь есть разные способы реализации

2.1. Использовать базу данных одного из приложений как "общую" в части справочников. Во втором приложении таблицы справочников не использовать. Обращаться к базе данных "головного" приложения
2.2. Выделить таблицы справочников в отдельное (третье) приложение/базу данных/свободные таблицы - это то, что Вы и сделали
2.3. Сделать одну общую базу данных для двух разных приложений - здесь сложности в именах полей/таблиц и структуре данных.

В последнем варианте придется заняться переименованием, если таблицы в разных приложениях имеют одинаковое имя, но это не справочники. Или наоборот, у "объединяемых" справочников разные имена полей/таблиц в разных приложениях. С другой стороны, первые 2 пункта можно рассматривать как первые шаги к такому объединению


Т.е. "идеальное" решение - это как раз общая база данных для разных приложений. Но это же и самое сложное с точки зрения процесса перехода. Потребуется длительный анализ кода на предмет того, как можно объединить структуры данных разных приложений

Самое простое с точки зрения понимания и написания кода - это синхронизация через лог. Но тут будут организационные сложности и некоторые "тормоза" при работе

Владимир Максимов
Самое простое с точки зрения понимания и написания кода - это синхронизация через лог.

А на мой взгляд, в данной ситуации самое простое - это ваши пункты 2.1 и 2.2, ничем принципиально не отличающиеся - ведь какая по большому счету разница, в каком "физическом месте" находится общая таблица? Открыл её и забыл об этом.

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

Вариант с синхронизацией любого рода я бы не рассматривал вовсе - она не является необходимой, а плюсы в доработке, о которых вы написали (я, правда, их не вижу, но допускаю, что вам виднее), могут с лихвой перекрыться её минусами в процессе дальнейшей эксплуатации.

Мне аргументы Сергея кажутся убедительными.

Владимир Максимов
Вы сильно торопитесь с кодом...

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

akvvohinc
...
А учитывая, что пункт 2.2 автор уже фактически реализовал, то надо его просто довести до ума, то есть понять, что было сделано неверно и поправить.

Так и сделал, и спасибо за помощь )

Taran

AndyNigmatec

Taran
И стоит ли их делить?

Полагаю такое "добро" уже досталось ТС, теперь ему что-то с этим делать ...

Взять и сделать правильно, а не городить костыли. Чтобы потом все-таки взять и сделать правильно.

Похоже, накаркал... (

> "Подвариант" синхронизации
Не связывайтесь с эитм посылом заказчика! Эти "бига дата", их "математика", отсутствует. Если вы способны СОВМЕЩАТЬ не таблицы а БД, ежесуточно, или непрерывно, то, подумайте, за что, и что в результате вы хотите получить

of63
> "Подвариант" синхронизации
Не связывайтесь с эитм посылом заказчика! Эти "бига дата", их "математика", отсутствует. Если вы способны СОВМЕЩАТЬ не таблицы а БД, ежесуточно, или непрерывно, то, подумайте, за что, и что в результате вы хотите получить

> Не связывайтесь с эитм посылом заказчика!
работайте с собой )

Доб. Зиповать (в онлайне, когда БД в исполь),,, придумывайте. )

В В процессе зиповки вы у же теряете данные за время зиповки?



Исправлено 2 раз(а). Последнее : of63, 12.11.22 21:16

Олег, не только лишь все умеют тебя понимать)))

Не сбивай с толку человека, все норм у него идет