Синхронизация таблиц

← →
мускул (2006-01-11 18:09) [0]

Господа, стоит задача синхронизации 2х таблиц. Как бы это попроще бы сделать. Можно ли это сделать в виде SQL-запроса? Под синхронизацией я подразумеваю именно не копирование, а приведение более старой таблицы к виду более новой за счет апдейтов / добавлений и удалений. Если это конечно возможно сделать просто...

← →
Anatoly Podgoretsky © (2006-01-11 18:14) [1]

Двухсторонея?

← →
френк (2006-01-11 18:28) [2]

синхронизация односторонняя

← →
мускул (2006-01-11 18:29) [3]

прошу прощение, забыл имя сменить ) да, синхронизация односторонняя. по сути требуется обновление старой таблицы до ее новейшего состояния.

← →
Asail (2006-01-11 18:40) [4]

> синхронизация односторонняя

А если так, то чем копирование не устраивоет?

← →
мускул (2006-01-11 18:57) [5]

проблема в том что пытаюсь уменьшить трафик по сети. ради этого все и затевалось.

← →
Anatoly Podgoretsky © (2006-01-11 19:00) [6]

Трафик уменьшится, если просто копировать, без анализа. Иначе придется пересылать теже объемы дважды и делать анализ.

← →
Anatoly Podgoretsky © (2006-01-11 19:01) [7]

И еше, а что в MySQL отсутствует репликация?

← →
мускул (2006-01-11 19:04) [8]

а если попробовать следующим макаром:

на локальной и удаленной таблице имеем по дополнительной колонке с хэшем, всяко меньше чем целиком вся запись. достаточно ведь по сути переслать хэш, проанализировать, провести синхронизацию. подскажите как можно в виде запроса сие провернуть?

← →
мускул (2006-01-11 19:05) [9]

вся проблема в том что мы имеем с одной стороны хост с мускулем, с другой стороны клиента с локальной БД (MS Access) необходимо запросом обновить таблицу в MDB в соответствии с данными MySQL"я.

← →
ANB © (2006-01-12 09:30) [10]

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

← →
evvcom © (2006-01-12 09:41) [11]

> Вывод - для экономии траффика лучше всего удалить данные
> в локальной таблице и полностью скопировать их с сервера.

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

← →
ANB © (2006-01-12 09:56) [12]

> evvcom © (12.01.06 09:41) [11]

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

← →
DELORAC © (2006-01-12 10:30) [13]

А что мешает в исходной таблице сделать поле (updated date) и смотреть спокойно по дате изменения.

← →
Anatoly Podgoretsky © (2006-01-12 13:49) [14]

А MySql поддерживает TIMESTAMP?
Насколько я знаю он далек от SQL 92/99

← →
мускул (2006-01-12 15:09) [15]

Anatoly Podgoretsky © (12.01.06 13:49) [14]
TIMESTAMP - тип данных? а хрен его знает. я в мускуле (не смотря на ник =) глубоко не залазил, а что, есть идея? ) щас гляну...

DELORAC © (12.01.06 10:30) [13]
не совсем понял. можно по поподробнее?

evvcom © (12.01.06 09:41) [11]
ANB © (12.01.06 09:56) [12]
вот и мне идея с хэшем нравится все больеш и больше ) можно ли одним запросом оформить сей анализ и апдейт?

← →
ANB © (2006-01-12 15:15) [16]

> мускул (12.01.06 15:09) [15]

Вряд ли обойдешься одним запросом. Апдейт тут вообще смысла иметь не будет. Если блок менялся его проще целиком перекачать.
А акссесс поддерживает гетерогенные запросы к MySQL ?

← →
Anatoly Podgoretsky © (2006-01-12 15:16) [17]

мускул (12.01.06 15:09) [15]
Это не тип данных, а автоматическая отметка сервера об версии строки.
Не путать с TIMESTAMP Интербейса.
Если поддерживает или есть аналог, то достаточно where fld>LastAccess
А для удаленных нужно через триггера вести таблицу удаленых.
А как все таки насчет штатной репликации - есть или нет?

← →
мускул (2006-01-12 15:41) [18]

ANB © (12.01.06 15:15) [16]
но никто не мешает мне через ZeosDB, к примеру, опрашивать удаленный mySQL-сервер, отправляя запросы. а потом их экспортировать в Access?

по поводу адейта осознал, спасибо.

Anatoly Podgoretsky © (12.01.06 15:16) [17]
полез копаться =)

← →
мускул (2006-01-12 16:27) [19]

репликация есть. но как-то все замороченно, немного запутался. разгребаю документацию =)

> можно ли одним запросом оформить сей анализ

Лучше написать хеш-функцию. Мускул поддерживает такое? А хеш вычислять не всякий раз при обращении, а лучше хранить отдельно и пересчитывать только для изменившихся блоков. Для update/insert написать триггерок, который определяя к какому блоку относится изменяемая строка, стирает хеш-значение, чтобы знать потом, что пересчитывать. Какой там мускул, 5 вроде триггера стал поддерживать?

← →
мускул (2006-01-12 20:04) [21]

evvcom © (12.01.06 16:51) [20]
угу с пятого есть. но мускуль у хостера четверка =( мало кто на пятый перешел ( спасибо за предложение.

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

с репликацией не допирает до меня пока ( но еще не ночь =)

ANB © (12.01.06 15:15) [16]
> А акссесс поддерживает гетерогенные запросы к MySQL ?
да. у него (вернее у jet-а) есть isam к odbc, а значит и доступ из запроса к любой базе имеющей odbc драйвер.

← →
мускул (2006-01-12 21:31) [23]

sniknik © (12.01.06 21:04) [22]
у Jet"a любой версии? тогда не буду мутить ту городьбу что начал. odbc для мускуля имеется. так и поступлю )

> у Jet"a любой версии?
а зачем тебе любой? на антиквариатные операционки нацелился? так и там нормальный сетап поставит то что нужно...

← →
мускул (2006-01-13 09:25) [25]

sniknik © (12.01.06 22:25) [24]
на всякий случай, просто интересно ) не то чтобы беспокоюсь, мало ли. support 9x пока с нашей стороны остается в силе, но уже завязываем =) по поводу сетапа согласен.

> на всякий случай, просто интересно )
в 3.5 вроде было (в реестре видел, но не пользовался), с более ранними не работал вообще. в текущей 4.0 есть, проверено.
4.0 уже года 3 (если не больше) как текущая и последняя (завязывают мелкософтцы с ней), нарваться на машину с меньшей версией практически невозможно (разве только специальную установку таклй оси сделать), гораздо больше шансов нарватся на полное отсутствие jet-а (но тоже небольшие. дал бы процентов 0,05 на такую вероятность... (на 600 установок. было (/известно. когда клиент сам справился не учитывается) 3 или 4 случая, такого полного отсутствия, 3.5 не попалась ни разу))

← →
мускул (2006-01-13 10:46) [27]

← →
мускул (2006-01-15 18:18) [28]

и снова я :)

в общем, отличная идея с TimeStamp"ом от АП. ну не давала она мне покоя. ведь по сути аналог TimeStamp"a можно организовать тригерами? или тут есть подводные камни? по идеи тригера на C/U/D и возможно служебную таблицу.

жаль что mySQL 5-ый не у всех стоит =(

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

с уважением.

Синхронизация таблиц Найти похожие ветки