Синхронизируйте данные между одинаковыми таблицами в файле mdb и схемой сервера MySQL - PullRequest
0 голосов
/ 21 апреля 2009

Я ищу способ управления синхронизацией между файлом Access mdb для приложения и схемой MySQL, содержащей копию тех же таблиц. Это произошло из-за того факта, что приложение не поддерживает MySQL как бэкэнд, но я ищу способ использовать MySQL для других офисных приложений, используя данные, которые генерирует первое приложение.

Некоторые дают:

1> Мы не можем отказаться от первого приложения, и оно совместимо только с Microsoft SQL Server в качестве внутреннего сервера для хранения данных.

2> Мы не против использования сервера Microsoft SQL, но стоимость лицензирования является серьезной проблемой, а также переписывает некоторые другие приложения Access, написанные для использования связанных таблиц и отдельных файлов MDB.

3> Сервер базы данных должен быть «дружественным к PHP» для будущего проекта расширения внутренней корпоративной сети.

4> Нет доступа к данным и доступа к ним вне корпоративной сети.

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

1 Ответ

3 голосов
/ 21 апреля 2009

Синхронизация двух баз данных очень и очень сложна, если обе базы данных должны быть обновляемыми. Если один является рабом другого, это не так сложно. Я не раз программировал именно этот тип синхронизации с помощью Access, один раз с MDB на веб-сервере, который должен был быть синхронизирован с локальной базой данных (для включения данных, отредактированных на веб-сайте; изменения не возвращались на веб-сайт, поэтому односторонняя синхронизация, но все же необходимо объединить правки не на веб-стороне), а также один раз запрограммировать синхронизацию между MySQL на веб-сайте и Access в отношении master (MySQL) / slave (Access).

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

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

  1. найдите новые записи и добавьте их в хранилище данных Access. Это легко сделать с помощью внешнего соединения.

  2. иметь дело с удалениями. Я буду обсуждать это позже, так как это, ну, конечно, сложно.

  3. иметь дело с обновленными записями. Для этого я написал код DAO, который будет писать SQL-операторы по столбцам.

Примерно так:

UPDATE LocalTable
SET LocalTable.Field1 = DownloadTable.Field2, LocalTable.Updated = DownloadTable.Updated
WHERE LocalTable.Field1 <> DownloadTable.Field2

Теперь, очевидно, предложение WHERE должно быть немного более сложным, чем это (вам приходится иметь дело с NULL, и вы должны использовать критерии, отформатированные соответствующим образом для типов данных, то есть с "" и ## для текста и даты, соответственно, и без разделителей для числовых данных), но написать код для этого довольно просто.

Скелетный код выглядит примерно так:

  Dim db As DAO.Database
  Dim rsFields As DAO.Recordset
  Dim fld As DAO.Field
  Dim strSQL As String

  Set rsFields = db.OpenRecordset("SELECT TOP 1 Field1, Field2, Field3 FROM LocalTable;")
  For Each fld in rsFields
    [write your SQL statement and execute it]
  Next fld
  Set fld = Nothing
  rsFields.Close
  Set rsFields = Nothing
  Set db = Nothing

Теперь, как я уже сказал, сложной частью является написание предложения WHERE для каждого оператора SQL, но это довольно легко понять. Кроме того, обратите внимание, что в вашем наборе записей rsFields (который используется только для обхода полей, которые вы хотите обновить) вы хотите включить только поля, которые можно обновлять, поэтому вы не указали бы поле CREATED и поле PK (и любые другие поля, которые вы не хотите обновлять).

Теперь для DELETES.

Вы можете подумать, что это хорошая идея - просто удалить любую запись в локальной таблице, которой нет в удаленной таблице. Это прекрасно работает, если это действительно ведомая база данных, но так часто то, что изначально является ведомым, в итоге получает свои собственные правки. Таким образом, в этом случае вам нужно , а не удалять записи из основной базы данных MySQL, и вместо этого иметь флаг DELETE, который помечает записи как удаленные. У вас может быть различная логика, которая может удалять удаленные записи из основной базы данных (например, если вы используете отметки даты в записях, вы можете удалить все записи, помеченные как DELETED, с отметкой времени LastUpdated, которая <= в последний раз, когда вы выгрузил данные; в качестве альтернативы приложение Access может отправить на сервер текстовый файл со списком записей, которые были успешно удалены из хранилища данных Access). Если в хранилище данных Access есть правки, вам понадобится логика для обработки там записи, которая была удалена из «основной» базы данных MySQL. </p>

В итоге:

Если у вас настоящие отношения хозяин / раб, это довольно тривиально. Если вы действительно хотите сделать это грубой силой, вы просто сбросите все таблицы данных MySQL в текстовые файлы, удалите все записи в хранилище данных Access и импортируйте текстовые файлы.

Я бы не стал этого делать, так как в первый раз, когда вам нужно отойти от отношений чистого хозяина / раба, вы попали в ловушку и должны все переписать с нуля.

Схема, которую я дал выше, будет работать очень чисто для master / slave, но также будет работать хорошо, если у вас есть несколько полей, которые являются частными для базы данных slave, или данные, которые существуют в slave, а не в master (в такой ситуации я работал).

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...