У меня есть две базы данных, MySQL и SQL Server. Я могу подключиться к обоим без каких-либо проблем. Моя проблема в том, что эта база данных MySQL использует идентификатор в качестве первичного ключа, но база данных SQL Server использует номер детали в качестве первичного ключа (программное обеспечение для бухгалтерского учета), но это меняется, когда клиент что-то меняет в настольном приложении.
Я хотел использовать такое утверждение Update * on Table WHERE id=PartNumber
,
но это не будет работать, так как номер детали изменится и больше не будет соответствовать идентификатору MySQL.
P.S. Я не могу ничего изменить в базе данных бухгалтерской программы.
П.П.С. Просто чтобы вы знали, что я могу вставлять в обе базы данных, но мне нужно обновить обе, чтобы они, так сказать, синхронизировались.
ОТРЕДАКТИРОВАНО
ОБРАЗЕЦ ДАННЫХ MySQL
ПРИМЕР ДАННЫХ MSSQL
ОТРЕДАКТИРОВАНО
Я нашел решение проблемы.
Мне нужно было использовать LEFT JOIN и INNER JOIN в сценарии, чтобы заставить его работать. Теперь я получаю SKU, чтобы ПОКАЗАТЬ.
SELECT
*,
wp_postmeta1.meta_value as SKU
FROM
wp_posts
LEFT OUTER JOIN
wp_postmeta pm
ON (wp_posts.ID = pm.post_id
AND pm.meta_key = '_thumbnail_id')
LEFT JOIN
wp_postmeta wp_postmeta1
on wp_postmeta1.post_id = wp_posts.ID
and wp_postmeta1.meta_key = '_sku'
WHERE
wp_posts.post_type = 'product'
Надеюсь, это поможет кому-то еще
Рассматривали ли вы удаление/вставку (возможно, с использованием слияния) вместо обновления?
Ваша ситуация не очень ясна, но предположим: пользователи меняют номер детали в бухгалтерской программе и, следовательно, первичный ключ, но только в sql-сервере. Теперь у вас есть приложение, которое управляет/получает доступ/синхронизирует обе базы данных, и вы пытаетесь не отставать? В этом случае ваша проблема заключается не в том, что MySQL использует идентификаторы как pk, а в том, что изменения pk не выполняются в обеих базах данных, поэтому вам нужно повторить их самостоятельно. Можете ли вы добавить триггеры и таблицу журнала (для регистрации изменений первичного ключа) в базу данных учета (не в программное обеспечение)? Может быть, у бухгалтерского программного обеспечения есть журнал, к которому вы можете получить доступ?
Ожидается, что значение поля со временем изменится, тогда оно не годится в качестве первичного ключа.
Есть два способа синхронизировать эти базы данных.
Во-первых, иметь неизменяемый ключ в базе данных MSSQL так же, как у вас есть первичный ключ в базе данных MySQL. Другим было бы вести журнал изменений номера детали в MSSQL, чтобы иметь возможность согласовать их с базой данных MySQL.
Есть еще третий и четвертый способ. Либо объясните пользователям, что они не могут изменить номер детали, потому что это все взорвет, либо... найдите новую работу. С технологической точки зрения нет другого способа синхронизировать эти БД.
Спасибо за совет, я искал некоторые рекомендации, и ваши самые полезные из всех. Я работаю над этим уже несколько недель, и вариант 4 показался мне хорошим вариантом. Я просто не могу поверить, что международная компания, занимающаяся программным обеспечением для бухгалтерского учета, не добавляет идентификатор в качестве первичного ключа, а затем у них есть разработчики в компании и за ее пределами почти на ежемесячной основе, поэтому никто не берет на себя ответственность за проблему, они просто продолжают передавать ее другим. новые ребята в компании. Я работаю не на них, а на их клиента, и именно здесь я начал замечать проблемы в базе данных.
Пожалуйста, предоставьте образцы данных и желаемые результаты. Я тоже не понимаю сути вопроса. Вам не нужно одно обновление для запуска обеих баз данных, не так ли?