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

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

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

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

или

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

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

Я использую DAAB и С# для своего DAL.

Спасибо!


database c# data-access-layer business-objects
person Element    schedule 14.01.2009    source источник
comment
можно уточнить вопрос?? Вы говорите о бизнес-объектах, а затем говорите об SQL. По крайней мере, я в замешательстве.   -  person Perpetualcoder    schedule 14.01.2009

Ответы (5)


arrow_upward
4
arrow_downward

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

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

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

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

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

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

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

arrow_upward
1
arrow_downward

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

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

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

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

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

person dkretz    schedule 14.01.2009

arrow_upward
0
arrow_downward

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

person Steven A. Lowe    schedule 14.01.2009

arrow_upward
0
arrow_downward

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

person Allain Lalonde    schedule 14.01.2009

arrow_upward
0
arrow_downward

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

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

person Daniel Auger    schedule 14.01.2009