Надлежащая(ые) методология(и) доступа к данным для инструмента планирования?

Я создаю/поддерживаю некоторые инструменты планирования со следующими характеристиками:

-данные загружаются (только для чтения) из MsAccess/SQLServer в платформу C# 3.5. Данные загружаются в SQLServer/MsAccess из системы ERP.

- Загружаются значительные объемы данных обслуживания (скажем, всего 2000 000 записей из различных таблиц), все эти данные необходимы одновременно для планирования.

В настоящее время я использую типизированные таблицы данных, которые я заполняю с помощью tableadapter. Затем я перебираю строки в каждой таблице, создавая пользовательские объекты, которые содержат одни и те же данные. Остальная часть моего кода работает только с этими пользовательскими объектами.

Каковы альтернативы этому подходу и каковы плюсы и минусы альтернатив по сравнению с этим подходом с точки зрения удобства обслуживания и скорости загрузки (из SQL Server/MSAccess в память)?

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


person willem    schedule 07.09.2011    source источник
comment
Ваше использование SQLServer/MsAccess любопытно. Является ли ваш инструмент полунезависимым от базы данных?   -  person billinkc    schedule 07.09.2011
comment
Инструменту не нужно работать с оперативными данными, данные SQLServer можно заполнить за одну ночь, чтобы снизить нагрузку на сервер.   -  person willem    schedule 07.09.2011
comment
Каковы проблемы, которые вы испытываете на данный момент с вашим подходом?   -  person Ivo    schedule 07.09.2011
comment
Я добавил комментарий о проблемах, с которыми я сталкиваюсь. Кроме того, я не уверен в ремонтопригодности.   -  person willem    schedule 07.09.2011


Ответы (2)


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

Но, опять же, если он работает нормально, как есть, то все в порядке.

p.s. Как и billinkc, меня интересует msAccess — сможет ли он действительно хорошо работать с такими объемами данных?

person J. Ed    schedule 07.09.2011

Ради производительности и чтобы не изобретать велосипед, я бы настоятельно рекомендовал использовать библиотеку ETL, например RhinoETL.

person JP.    schedule 07.09.2011