Как бы вы перенесли сотни баз данных MS Access в центральную службу?

Question

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

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

Нет никаких реальных ограничений на СУБД (Oracle, сервер MS SQL) или стек, на котором она будет работать (LAMP, ASP.net, Java), и для этого явно не будет серебряной пули. Мы хотели бы что-то, что может удалить начальную работу в автоматическом режиме.

Answer 1

Мы увеличиваем размер (используя мастер увеличения или вручную) пользователей до сервера SQL. Обычно это довольно просто. Замените все таблицы доступа связанными таблицами с сервером sql и держите все формы / отчеты / макросы в доступе. Инвестиции в доступ не теряются, и пользователи могут продолжать вести бизнес как обычно. Вы получаете надежность сервера sql и централизованного резервного копирования. Имейте в виду - мы сделали это для нескольких больших баз данных, а не для сотен. Я бы сделал несколько десятков пилотов и посмотрел бы, как это работает.

UPDATE: Я только что нашел это, помощник по миграции SQL Server, это может стоить посмотреть: http://www.microsoft.com/sql/solutions/migration/default.mspx

Обновление: да, для плохо спроектированных баз данных потребуется некоторый рефакторинг. Что касается того, как обрабатывать разрастание доступа? Я сталкивался с этим в компаниях с большим количеством технических пользователей (инженеры, особенно, худшие для этого ... и превосходные разрастания). Мы провели аудит - (после резервного копирования) удалили все базы данных, которые не были затронуты более года. «Владельцы» назначались на основании местоположения и / или данных в базе данных. Если база данных была в «S: \ quality \ test_dept», то менеджер по качеству и главный инженер по тестированию должны были стать ее владельцем, или мы удалили ее (снова после ее резервного копирования).

Answer 2

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

Хотя это не совсем ответ на вопрос.

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

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

Answer 3

Oracle располагает рабочим столом миграции для переноса систем MS Access на Oracle Application Express, который стоит изучить.

http://apex.oracle.com

Answer 4

В дополнение к комментариям Дэвида Фентона

Ваше административное правило будет примерно таким:

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

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

Answer 5

Так? Выделите сервер для ваших баз данных Access.

Теперь у вас есть возможность отслеживания использования, а также возможность уделять больше внимания некоторым важным децентрализованным данным, хранящимся в этих приложениях.

Это то, что вы собирались делать в любом случае, только вы хотели использовать другой движок базы данных вместо NTFS.

А теперь вам нужно заставить пользователей зайти на ваш сервер.

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

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

Простой способ обновления, улучшенный сервис для пользователей, улучшенная централизация и контроль за ИТ. Каждый победитель.