Должен ли я генерировать сложный объект в базе данных или на уровне доступа к данным?

Question

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

Сам объект (заявка) не очень сложен, но из-за характера данных и организации базы данных получение данных заявки очень сложно. Я не могу просто соединить все таблицы вместе и получить данные. Мне нужно выполнить «базовый» запрос, чтобы получить основы заявки, а затем собрать дополнительные данные о претензии, основанные на различных проблемах.

Было бы лучше при работе с этими данными:

1. Создайте объект в хранимой процедуре, где все соответствующие данные легко доступны, и выполните итерации по табличной переменной (используя SQL Server 2005), чтобы собрать воедино всю дополнительную информацию.

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

3. Используйте инструмент OR / M и наметьте все сложные ситуации для генерации объекта.

4. Что-то еще.

РЕДАКТИРОВАТЬ: Просто чтобы прояснить некоторые из вопросов, перечисленных ниже. Сложность действительно не проблема бизнеса. Если в заявке указан код типа «UB», то я должен извлечь некоторые дополнительные данные из таблицы X. Если в заявке указан код типа «HCFA», то мне придется извлечь некоторые данные из таблицы Y Это такие вещи. Надеюсь, это поможет.

Answer 1

В этом случае еще один голос за хранимые процедуры.

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

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

Вы не хотите попадать в ситуацию, когда незначительные ошибки и случайные случаи в избыточных реализациях приводят к тому, что разные приложения видят данные немного по-разному. СУХОЙ, и все такое.

Answer 2

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

Answer 3

Я бы использовал хранимую процедуру по соображениям безопасности. Вам не нужно предоставлять привилегии SELECT используемым таблицам утверждений, которые звучат несколько важно. Вы только должны предоставить пользователю доступ к этой хранимой процедуре. Если у пользователя базы данных уже есть привилегии SELECT для таблиц, я не вижу ничего плохого в создании объекта на уровне доступа к данным. Просто будьте последовательны с любым вариантом, который вы выберете. Если вы используете хранимые процедуры в другом месте, продолжайте использовать их здесь. То же самое относится и к генерации объектов на уровне доступа к данным.

Answer 4

Хранимые процедуры плохие, хорошо?

Похоже, что в этом случае представления будут лучше, чем хранимые процедуры.

Если вы используете .NET, я настоятельно рекомендую использовать ORM для получения поддержки Linq.

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

В конце концов, любое решение, скорее всего, будет работать. Вы не сталкиваетесь с решением типа «сделай или сломай». Просто двигайтесь, не зацикливайтесь на такого рода проблемах.

Answer 5

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

Answer 6

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

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

Я не отступаю от этого выбора слегка *.

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

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

Answer 7

Я не фанат продвижения бизнес-логики до уровня персистентности, поэтому я бы не рекомендовал вариант 1. Подход, который я бы выбрал, включает в себя наличие четко определенного программного объекта, который моделирует базовый объект базы данных, ORM ориентирован, но ваш вариант 3 звучит так, как будто вы думаете об этом как обременительном задании по отображению, чего я на самом деле не считаю. Я бы просто имел логику, необходимую для загрузки всего, что вас беспокоит, с этим объектом, настроенным в методах программного объекта, моделирующего его.