Как перейти с MS Access на SQL Server 2005?

Question

У меня есть приложение Windows VB.NET, которое извлекает информацию из базы данных MS Access. Основная роль приложения - извлекать информацию из файлов Excel в различных форматах, стандартизировать структуру файлов и записывать ее в файлы CSV. Приложение использует MS Access в качестве источника ключей и файлов перекрестных ссылок.

Приложение Windows использует типизированные наборы данных для большей части взаимодействия пользователя с базой данных. Стандартизация выполняется на каждом клиентском компьютере. Приложение не ... как я могу сказать это ... БЫСТРО: -).

Вопрос: Каков наилучший способ переноса БД и приложения на SQL Server 2005. Я думаю, что было бы неплохо написать код для стандартизации в пакетах SSIS и в них.

Каков подходящий способ перехода?

---

Приложение извлекает данные из 250 файлов Excel каждую неделю и приблизительно 800 файлов каждый месяц, в среднем около 5000 строк на файл. Существует 13 различных форматов файлов, которые стандартизированы и представлены в трех различных стандартных форматах. Приложение занимает от 25 мин. и 40 минут для запуска в зависимости от того, какие данные мы запускаем. 95% заявок составляет процесс стандартизации. Все, что пользователь делает, это выбирает несколько параметров и запускает прогон.

Answer 1

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

Answer 2

В качестве отправной точки можно использовать мастер увеличения размера.

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

Если вы не сильно ударили по Access, я сомневаюсь, что это ваше узкое место.

Что касается чтения файлов Excel, SSIS может это делать, но это может быть не так надежно, как механизм, который вы используете в VB.NET прямо сейчас, если ваш код VB.NET имеет много умной логики для решения со степенью вариации во входных файлах

Что касается записи данных в CSV, SSIS в порядке, и я нашел SSIS довольно хорошим исполнителем.

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

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

Answer 3

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

Answer 4

Еженедельно, для каждого клиента: 250 файлов за 25 минут = 10 файлов в минуту или 6 секунд на файл.

Ежемесячно, за клиента: 800 файлов за 40 минут = 20 файлов в минуту или 3 секунды на файл.

Мое ожидание будет меньше 1 сек. за файл (5000 строк), включая:
а. Импортировать или прикрепить xls к mdb,
б. Преобразование через Access SQL
с. Экспорт в CSV

Единственное объяснение, которое приходит на ум, заключается в том, что, возможно, приложение .NET считывает, преобразовывает и сохраняет строки одновременно. Возможно ли это так?

Если вы преобразуете в SSIS, то это, вероятно, устареет .NET-приложение, потому что SSIS захочет обрабатывать ETL (и сохранять) сам. Таким образом, вы будете в основном переписывать программное обеспечение. Но у вас могут быть лучшие ресурсы для SSIS, чем для Access. Но это кажется мне излишним. Но тогда .NET, а не VBA также может быть излишним; и переписывание в VBA тоже работа. Думаю, что наименьшим усилием я бы хотел посмотреть, сможете ли вы сделать весь ETL (и сохранить), используя Access SQL для большинства из них, и используя VBA только для сценариев, чтобы перебирать входные файлы в каталоге или что-то подобное.

Я думаю, что вы могли бы, по крайней мере, создать прототип базовых сценариев использования и выяснить, сможете ли вы довольно быстро выяснить, где сейчас тратится время (как это было предложено в предыдущих ответах). Но это стоило бы выяснить, прежде чем выделять ресурсы для реконструкции. направлены на неправильную часть проблемы. Если бы вы могли немного расширить эти области, я бы, вероятно, направил вас дальше. Но Access довольно хорошо подходит для такого рода вещей: (ИМХО) более низкая совокупная стоимость владения, чем у SQL Server + SSIS + .NET.

Не говоря уже о том, что я был бы удивлен, если бы файлы CSV были истинной конечной точкой, которая может играть роль в принятии решения. Разве данные Excel на самом деле не оказываются дальше по пути?

Наконец, насколько нежелательным является 25-40-минутный процесс, который, по-видимому, не обслуживается, может работать в обеденный перерыв и, возможно, в основном работает нормально?

---

Примечания:

Per week    

Excel Files 250
Minutes 25
Minutes/File    0.1
Sec/File    6


Per month   

Excel files 800
Minutes 40
Minutes/File    0.05
Sec/File    3

Answer 5

Убедитесь, что область видимости ясна:

1. Используйте программу .NET для
2. управляет интерфейсом базы данных Access, который позволяет вам
3. Извлечение данных из нескольких таблиц Excel,
4. Массируя данные соответствующим образом, и
5. Сохранить результат в CSV-файле.

О каких объемах мы говорим? Сколько клиентов, сколько электронных таблиц на одного клиента, сколько строк в электронной таблице (я думаю, это будет 32767 макс. Для одной электронной таблицы, верно? И сколько времени мы говорим?

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

Похоже, этого недостаточно для того, чтобы обеспечить значительное время для хорошо спроектированного внешнего интерфейса базы данных Excel, чтобы выполнить весь процесс с использованием VBA. Если ваш вариант предусматривает установку и работу SQL Server (вместо Access) на каждом клиенте, я был бы удивлен, если бы административные и эксплуатационные расходы не увеличились.