Re: копирование таблиц | |
---|---|
Taran Сообщений: 13626 Откуда: Красноярск Дата регистрации: 16.01.2008 |
Так это всё упрощает. Маленько пошел не тем путём. Надо было не новую программу писать, а имеющуюся доращивать. Ежели конечно она в исходниках доступна. |
Re: копирование таблиц | |
---|---|
Владимир Максимов Сообщений: 14100 Откуда: Москва Дата регистрации: 02.09.2000 |
Вы сильно торопитесь с кодом. Сначала надо решить, что и зачем делать. Потом уже выбирать "как делать"
Проблема выглядит следующим образом Существуют два независимых приложения со своими базами данных. Как следствие, свои справочники в каждом приложении. Однако пользователи ожидают, что если создали/изменили запись справочника в одном приложении, то это изменение должно отразится и в другом приложении. Какие есть варианты решения проблемы. В принципе, все их уже озвучили, но если обобщить, то 1. Синхронизация 2. Одно место для хранения данных по справочникам Это в самом общем виде. Каждый из этих вариантов имеет еще кучу своих вариантов решения 1. Синхронизация В самом общем виде, это означает, что любые изменения в любом приложении автоматически копируются в другое приложение. Но для решения этой задачи должен существовать общий идентификатор записей. Одинаковый в обоих приложениях. Просто чтобы понимать какая запись новая, а какая - это изменение существующей записи Теоретически, для контрагентов можно было бы использовать их УНП (ИНН в РФ), но практика показывает, что это не вполне надежное решение. Пользователь может не знать или могут оказаться одинаковые значения у разных записей. Поэтому в таких случаях делают взаимную идентификацию. Т.е. в справочнике одного приложения делают ссылку на запись другого приложения (новое поле в таблице). Обновление этих ссылок в момент синхронизации. А первый раз эти ссылки следует проставить вручную. Т.е. в приложении 1 в справочнике контрагентов указать код записи из приложения 2. И наоборот. В приложении 2 в справочнике контрагентов указать код записи из приложения 1 Тогда в момент внесения изменения в справочнике в одном приложении по значению кода из другого приложения находим соответствующую запись и копируем в нее сделанные изменения. Если нет кода из другого приложения, то это новая запись. Надо создать новую запись в другом приложении и обменяться кодами. Тут следует заметить, что копировать не обязательно вообще все данные справочника. Как уже говорили, синхронизировать (копировать) надо только те данные, которые должны быть общие в этих приложениях Такую синхронизацию можно делать "на лету" в момент изменения (триггера в DBC или просто дополнительный код там, где происходит сохранение изменений справочника). Или же сделать некую периодическую операцию, которая раз в 5 минут (полчаса, час, раз в день) делает такое сравнение и обновление. Разумеется, если такая задержка обновления допустима "Подвариант" синхронизации - это в момент сохранения изменения в таблице делать запись в лог изменений. В каком приложении, в какой записи что изменили. А в процедуре синхронизации по этому логу делать соответствующие изменения в другом приложении. Лог - это дополнительный аргумент в случае каких-либо конфликтных ситуаций с пользователями. С логом можно еще так поступить. При обращении к справочнику сначала смотреть на лог. Если там есть не обработанные записи (изменения в другом приложении), то выполнить обновление в текущем приложении. Т.е. при изменении в справочнике делаем запись в лог, а при чтении справочника - сначала выполняем обновление из лога. Если оформить этот самый лог как свободную таблицу, то отпадает необходимость обращения к базам данных другого приложения В общем, разные варианты есть... Синхронизация удобна тем, что практически не требует изменения в самих приложениях и данных. Но здесь возникают некоторые организационные сложности. Т.е. ситуация, когда будут расхождения в справочниках в разных приложениях все-таки возможна. Ведь данные физически в двух разных местах и, например, произошел сбой синхронизации по какой-либо причине 2. Одно место для хранения данных по справочникам Ну, это как раз то, что Вам "интуитивно понятно". Но и здесь есть разные способы реализации 2.1. Использовать базу данных одного из приложений как "общую" в части справочников. Во втором приложении таблицы справочников не использовать. Обращаться к базе данных "головного" приложения 2.2. Выделить таблицы справочников в отдельное (третье) приложение/базу данных/свободные таблицы - это то, что Вы и сделали 2.3. Сделать одну общую базу данных для двух разных приложений - здесь сложности в именах полей/таблиц и структуре данных. В последнем варианте придется заняться переименованием, если таблицы в разных приложениях имеют одинаковое имя, но это не справочники. Или наоборот, у "объединяемых" справочников разные имена полей/таблиц в разных приложениях. С другой стороны, первые 2 пункта можно рассматривать как первые шаги к такому объединению Т.е. "идеальное" решение - это как раз общая база данных для разных приложений. Но это же и самое сложное с точки зрения процесса перехода. Потребуется длительный анализ кода на предмет того, как можно объединить структуры данных разных приложений Самое простое с точки зрения понимания и написания кода - это синхронизация через лог. Но тут будут организационные сложности и некоторые "тормоза" при работе |
Re: копирование таблиц | |
---|---|
akvvohinc Сообщений: 4224 Откуда: Москва Дата регистрации: 11.11.2008 |
А на мой взгляд, в данной ситуации самое простое - это ваши пункты 2.1 и 2.2, ничем принципиально не отличающиеся - ведь какая по большому счету разница, в каком "физическом месте" находится общая таблица? Открыл её и забыл об этом. А учитывая, что пункт 2.2 автор уже фактически реализовал, то надо его просто довести до ума, то есть понять, что было сделано неверно и поправить. Вариант с синхронизацией любого рода я бы не рассматривал вовсе - она не является необходимой, а плюсы в доработке, о которых вы написали (я, правда, их не вижу, но допускаю, что вам виднее), могут с лихвой перекрыться её минусами в процессе дальнейшей эксплуатации. |
Re: копирование таблиц | |
---|---|
sphinx Сообщений: 31189 Откуда: Каменск-Уральски Дата регистрации: 22.11.2006 |
Мне аргументы Сергея кажутся убедительными.
------------------ "Veni, vidi, vici!"(с) |
Re: копирование таблиц | |
---|---|
DmitryKn Сообщений: 300 Дата регистрации: 06.04.2022 |
Спасибо за развернутый ответ, всегда рад вашим комментариям. Остановился на п.2.2. , поправил огрехи, пока полет нормальный. |
Re: копирование таблиц | |
---|---|
DmitryKn Сообщений: 300 Дата регистрации: 06.04.2022 |
Так и сделал, и спасибо за помощь ) |
Re: копирование таблиц | |
---|---|
DmitryKn Сообщений: 300 Дата регистрации: 06.04.2022 |
Похоже, накаркал... ( |
Re: копирование таблиц | |
---|---|
of63 Сообщений: 25256 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
> "Подвариант" синхронизации
Не связывайтесь с эитм посылом заказчика! Эти "бига дата", их "математика", отсутствует. Если вы способны СОВМЕЩАТЬ не таблицы а БД, ежесуточно, или непрерывно, то, подумайте, за что, и что в результате вы хотите получить |
Re: копирование таблиц | |
---|---|
of63 Сообщений: 25256 Откуда: Н.Новгород Дата регистрации: 13.02.2008 |
> Не связывайтесь с эитм посылом заказчика! работайте с собой ) Доб. Зиповать (в онлайне, когда БД в исполь),,, придумывайте. ) В В процессе зиповки вы у же теряете данные за время зиповки? Исправлено 2 раз(а). Последнее : of63, 12.11.22 21:16 |
Re: копирование таблиц | |
---|---|
AndyNigmatec Автор Сообщений: 1574 Откуда: Волгоград Дата регистрации: 28.06.2015 |
Олег, не только лишь все умеют тебя понимать)))
Не сбивай с толку человека, все норм у него идет |
© 2000-2024 Fox Club  |