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

Question

Я рассматриваю возможность проекта по переносу очень большого приложения MS Access на новую систему, основанную на SQL Server.Существующая система - это, по сути, приложение ERP с парой дюжин пользователей, которые совместно используют базу данных Access по сети.База данных насчитывает около 300 таблиц и много грязного кода VBA.Эта система начинает выходить из строя (на самом деле, удивительно, что она работала так долго, как и сейчас).

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

Я рассмотрел использование чего-то вродеADO.NET Entity Framework для реализации уровня абстракции данных, чтобы справиться с этим, но, насколько я могу судить, Entity Framework не имеет поставщика доступа.

Кажется ли мой подход разумным?Какие еще стратегии использовали люди для достижения аналогичных целей?

Answer 1

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

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

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

Answer 2

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Удачи!

Answer 3

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

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

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

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

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

Answer 4

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

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

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

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

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

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

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

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