Лучше запрашивать БД или загружать табличные данные в объект в сборке CLR?

Я импортирую плоский файл в БД через сборку CLR.
Для каждой строки в плоском файле сборка выполняет несколько проверок качества. Я заметил, что хранение таблиц БД в DataTables и выполнение запросов к этим DataTables происходит намного медленнее, чем прямой запрос к БД. С другой стороны, HashSet кажется таким же быстрым, как и запрос к БД.

На данный момент мой код иногда загружает данные в HashSet и запрашивает HashSet для каждой строки, а иногда проверяет БД отдельно для каждой строки. Например, когда я проверяю, существует ли ключ в исходной строке в базе данных для ~10 000 исходных строк и ~1000 возможных правильных ключей.
HashSet:
+ я запрашиваю БД только один раз, и сборка может выполнять свои проверки в HashSet.
– Зачем копировать то, что уже существует в БД?
Запросить БД:
+ БД содержит структуру таблицы и оптимизирован для таких запросов.
- Мне нужно управлять соединением с БД, что может включать многократное открытие/закрытие соединения с БД.

Я хочу стандартизировать свой код и нуждаюсь в помощи, чтобы решить, какой вариант использовать? Я не вижу разницы в производительности для себя. Если открытие DB-соединения из CLR-сборки не является проблемой, то я бы предпочел запросить БД, поскольку затем я могу просто написать код SQL в свою CLR-сборку и выполнить его, а не кодировать несколько объектов. .

Есть ли техническая причина использовать один вместо другого?
Рекомендация по стилю написания кода?

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

Возможно, связанный с этим вопрос.


person Rafael Emshoff    schedule 25.03.2014    source источник


Ответы (1)


Я буду голосовать за HashSet. Поскольку нет существенной разницы в DB и HashSet. Когда у вас есть все с вами в системе, вам не нужно беспокоиться о соединениях вызовов БД и обо всем этом.

– Зачем копировать то, что уже существует в БД?

Эта репликация избавит вас от необходимости снова и снова обращаться к БД, вы можете поиграться с данными в системе.

person Dnyanesh    schedule 25.03.2014