Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Синхронизация таблиц [D7, MySQL]

Страницы: 1 2 >
мускул © (2006-01-11 18:09:00)
Господа, стоит задача синхронизации 2х таблиц. Как бы это попроще бы сделать. Можно ли это сделать в виде SQL-запроса? Под синхронизацией я подразумеваю именно не копирование, а приведение более старой таблицы к виду более новой за счет апдейтов / добавлений и удалений. Если это конечно возможно сделать просто...

мускул (2006-01-15 18:18:00) [1]
и снова я :)

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

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

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

с уважением.

мускул (2006-01-13 10:46:00) [2]
sniknik © (13.01.06 10:41) [26]
спасибо большое.

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

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

sniknik (2006-01-12 22:25:00) [5]
> у Jet'a любой версии?
а зачем тебе любой? на антиквариатные операционки нацелился? так и там нормальный сетап поставит то что нужно...

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

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

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

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

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

evvcom (2006-01-12 16:51:00) [9]

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

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

мускул (2006-01-12 16:27:00) [10]
репликация есть. но как-то все замороченно, немного запутался. разгребаю документацию =)

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

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

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

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

ANB (2006-01-12 15:15:00) [13]

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

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

мускул (2006-01-12 15:09:00) [14]
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]
вот и мне идея с хэшем нравится все больеш и больше ) можно ли одним запросом оформить сей анализ и апдейт?

Anatoly Podgoretsky (2006-01-12 13:49:00) [15]
А MySql поддерживает TIMESTAMP?
Насколько я знаю он далек от SQL 92/99

DELORAC (2006-01-12 10:30:00) [16]
А что мешает в исходной таблице сделать поле (updated date) и смотреть спокойно по дате изменения.

ANB (2006-01-12 09:56:00) [17]

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

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

evvcom (2006-01-12 09:41:00) [18]

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

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

ANB (2006-01-12 09:30:00) [19]
Порассуждаем логически : чтобы обновить / добавить запись данные с удаленного сервера все равно придется передать. Для удаления лишних записей придется опять таки слазить на сервер и посмотреть, есть там такая запись или нет. Вывод - для экономии траффика лучше всего удалить данные в локальной таблице и полностью скопировать их с сервера.

мускул (2006-01-11 19:05:00) [20]
вся проблема в том что мы имеем с одной стороны хост с мускулем, с другой стороны клиента с локальной БД (MS Access) необходимо запросом обновить таблицу в MDB в соответствии с данными MySQL'я.

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »