Загрузка иерархии бизнес-объектов одним вызовом базы данных

Question

Хотелось бы узнать, как лучше всего заполнять структуру иерархии бизнес-объектов (родитель / ребенок / внук) из одного вызова базы данных.

Я могу придумать пару способов добиться этого, например:

Соединение слева во всех отношениях в моем SQL-выражении, затем использование циклов и логики для заполнения бизнес-объектов

или

используйте несколько операторов select и 1 datareader и используйте его метод NextResult (), чтобы перебрать каждый набор результатов и заполнить соответствующие BO

Просто интересно, какая лучшая практика для этого

Я использую DAAB и c # для моего DAL

Спасибо!

Answer 1

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

• выборка данных из базы данных
• заполнение бизнес-объектов

Выборка данных из базы данных на несколько порядков медленнее, чем создание объектов в памяти. Лучшим способом было бы создать операторы select для быстрого доступа к данным.

Запросы могут быть построены тремя способами:

• один большой запрос, который выбирает все за одно выполнение - вы получите самый сложный SQL и, возможно, самое быстрое выполнение (зависит от схемы БД)
• мастер / подробный подход - простые запросы. много трафика в базу данных. Это допустимо, только если вы выбираете небольшое количество записей, в противном случае это очень медленно.
• гибрид: один запрос для каждого уровня иерархии. Рассмотрим этот подход, если два предыдущих способа замедлились. Этот подход требует более сложной логики для заполнения бизнес-объектов.

Вы должны решить, какое решение является приемлемым. Некоторые ключевые моменты для рассмотрения:

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

Answer 2

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

Я слежу за размерами набора результатов, но в контексте любого приложения, с которым я столкнулся, это не было проблемой. В общем, я не сожалел об этом, но YMMV.

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

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

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

Answer 3

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

Answer 4

Рассматривали ли вы использование OR Mapper, например, NHibernate? Стремительная загрузка может сделать то, что вы просите за один звонок в базу данных.

Если OR Mapper не является выбором, я бы проголосовал за datareader.NextResultSet.

Answer 5

DataReader NextResult является лучшим, так как объем данных, проходящих по каналу, растет не так быстро, как подход с присоединением.