Какие стратегии доступны для переноса баз данных Access в приложения на основе сервера SQL?

Мы столкнулись с похожей ситуацией несколько лет назад, но с самого начала знали, что однажды нам придется переключиться на SQL SERVER, поэтому весь код был написан для работы с клиентом Access с базами данных как Access, так и SQL-сервера.

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

В дополнение к этому, как сказал @mjv, другим недостатком одноразового перехода на MS SQL является то, что вы унаследуете многие проблемы из исходной базы данных: неправильные или несоответствующие имена полей, несоответствующие политики первичного/внешнего ключа, скрытые отношения «один ко многим», которые вы хотели бы реализовать в новой модели базы данных и т. д.

Я предложу здесь некоторые принципы и правила для реализации решения «мягкого перехода», которое явно лучше всего подходит вам. Сразу скажу, что это будет непросто, но определенно очень интересно, особенно при работе с 300 столами! Повезло тебе!

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

По моему мнению, лучшее решение сильно зависит от:

1. Оригинальная технология подключения и способ управления данными в коде вашего клиента: доступ к связанным таблицам, ODBC, ADODB, набору записей, локальным таблицам, источникам записей форм, пакетное обновление и т. д.
2. Возможность разделить ваши таблицы и ваше приложение на «в основном независимые» модули.

И вы не пожалеете следующих обязательных мероприятий:

1. настройка процедуры переноса из базы данных Access на SQL сервер. Вы можете использовать уже существующие инструменты (Мастер увеличения доступа очень плохой, поэтому не стесняйтесь покупать настоящий, например SSW или EMS SQL Manager, очень мощный) или создать свой собственный с помощью Visual Basic. Если вы планируете внести некоторые изменения в определение данных, вам определенно придется написать код. Имейте в виду, что вы будете запускать этот код много-много раз, поэтому убедитесь, что он включает все инструкции по экономии времени, которые позволят вам перезапускать процесс с самого начала столько раз, сколько вы хотите. При импорте данных вам придется выбирать между двумя основными стратегиями импорта данных:

    a - DELETE existing record, then INSERT imported record
    b - UPDATE existing record from imported record
   

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

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

2. реализовать в коде вашего клиента возможность подключения как к исходной базе данных ms-access, так и к новому серверу MS SQL. В идеале вы должны иметь возможность управлять из своего кода обоими подключениями для отображения и проверки данных.

   Эта возможность будет реализована модулями, где у вас будет для каждого из них «пробный период», т.е. возможность выбора во время тестирования между соединением доступа и соединением sql при использовании модуля. После завершения тестирования модуль можно запустить в монопольном режиме SQL-сервера.

В течение периода передачи, который может длиться несколько месяцев, вам придется программно управлять ограничениями базы данных, которые существуют между модулями «SQL-сервер» и модулями «Доступ». Возвращаясь к нашему примеру с клиентами/выставлением счетов, модуль клиентов будет сначала переключен на MS SQL. Прежде чем можно будет переключить модуль выставления счетов, вам придется программно реализовать отношение «один ко многим» между клиентами и счетами, где каждая из таблиц будет находиться в другой базе данных. Такое ограничение можно реализовать в форме «Счет-фактура», заполнив поле со списком «Клиенты» набором записей «Клиенты» с сервера SQL.

Мое предложение состоит в том, чтобы создавать ваши модули в соответствии с вашей моделью базы данных, всегда начиная с таблиц «один» или ваших отношений «один ко многим»: основные списки, такие как «Единицы», «Валюты», « Страны», должны быть переключены в первую очередь. Вы получите первый практический опыт написания кода для передачи данных и управления вторым подключением в клиентском интерфейсе. Затем вы сможете «подняться» в своей модели базы данных, переключив таблицы «продукты» и «клиенты» (где единицы измерения, страны и валюты являются внешними ключами) на новый сервер.

Удачи!

Вы можете обнаружить, что основная проблема заключается в использовании механизма MS Access JET в качестве серверной части. Я предполагаю, что у вас есть Access FE (внешняя часть) со всеми объектами, кроме таблиц, и BE (внутренняя часть — только таблицы).

Вы можете обнаружить, что перенос данных на SQL Server и привязка к нему Access FE поможет немедленно устранить проблемы.

Затем, если вы не хотите продолжать использовать MS Access в качестве FE, вы можете рассмотреть возможность разделения его на «модули» и перепроектировать модули один за другим, используя отдельную платформу разработки.

Я бы поддержал предложение увеличить серверную часть до SQL Server в качестве шага 1.

Однако я бы никогда не перешел к предложенному шагу 2 (т. е. замене внешнего интерфейса Access чем-то другим). Вместо этого я бы предложил приложить усилия для исправления недостатков схемы и настройки приложения Access для работы с новой схемой.

Очевидно, что никогда не бывает так, что все просто работает отлично, когда вы увеличиваете размер - некоторые вещи, которые раньше были довольно быстрыми, станут собаками, а некоторые вещи, которые раньше были довольно медленными, станут быстрыми. И я обнаружил, что очень часто проблемы оказываются не там, где вы их ожидаете. Выяснить, что нужно исправить, можно только путем тестирования.

По сути, все, что работает плохо, перестраивается или полностью перемещается на серверную часть.

Используйте инвестиции в существующее приложение Access вместо того, чтобы выбрасывать все это и начинать с нуля. Доступ является прекрасным интерфейсом для серверной части SQL Server, если вы не предполагаете, что он будет работать точно так же, как с серверной частью Jet/ACE.

...мысли вслух... Думаю, это может сработать.

Мне кажется, что сложность приложения заключается в различных модулях VBA, а не в самой таблице/схеме базы данных. Таким образом, возможным путем миграции может быть сначала перенести хранилище данных на сервер SQL точно так, как есть, как показано ниже:

• предотвратить любое изменение данных в течение нескольких часов
• дублировать все таблицы на SQL-сервер; обязательно создайте такие же индексы.
• создавать связанные таблицы с источником ODBC, указывающим на вновь созданные таблицы на SQL Server
  , эти таблицы должны иметь то же имя, что и исходные таблицы (поэтому может потребоваться переименование, скажем, с подчеркиванием в начале, для возможной ссылки).
• Теперь приложение можно перезапустить, и оно должно использовать таблицы SQL, а не таблицы Access. Вся логика должна работать как раньше (правильно...), возможная медлительность в зависимости от расстояния между двумя машинами.

Все вышеперечисленное можно проверить примерно за день работы или около того; наиболее утомительным является создание таблиц на сервере SQL (многое из этого можно автоматизировать, я уверен). Следующая наиболее утомительная задача — утверждать, что приложение эффективно работает, как и раньше, но с его хранением на SQL.
EDIT: как было предложено в комментарии, я должен подчеркнуть, что существует [справедливая?] вероятность того, что приложение не будет работать так гладко под серверной частью SQL-сервера, и может потребоваться несколько недель тяжелой работы по тестированию и исправлению. Однако, если некоторые из этих трудностей нельзя предвидеть из-за понимания приложения, не выраженного в вопросе, я предлагаю рассмотреть попытку миграции «как есть» на SQL Server; в конце концов, это может сработать с минимальными усилиями, а если нет, мы узнаем об этом очень быстро. Таким образом, это высокодоходное предложение с низким уровнем риска...

Основное преимущество при таком подходе заключается в том, что будет единое хранилище в течение [как ожидает OP] более длительного периода, в течение которого старое приложение Access будет сосуществовать с новым приложением.

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

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

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