database - 我应该在数据库或数据访问层生成一个复杂的对象吗？

Question

我正在为我们的一个部门开发包含医疗数据的应用程序。它与我们这里的第三方系统接口(interface)。

对象本身(一个声明)并不是非常复杂，但是由于数据的性质和数据库的组织，检索声明数据非常复杂。我不能简单地将所有表连接在一起并获取数据。我需要执行“基本”查询以获取 claim 的基础知识，然后根据各种问题拼凑有关 claim 的补充数据。

在处理这些数据时会更好吗:

1. 在存储过程中生成对象，其中所有相关数据都随时可用，并循环访问表变量(使用 SQL Server 2005)以拼凑所有补充信息。

   <

2. 在数据访问层生成对象，我可以在其中进行更强大的数据操作，并进行一系列快速简单的调用来检索查找数据。

3. 使用 OR/M 工具并绘制出所有复杂情况以生成对象。

4. 其他。

编辑:只是为了澄清下面列出的一些问题。复杂性确实不是业务问题。如果声明的类型代码为“UB”，那么我必须从表 X 中提取一些补充数据。如果声明的类型代码为“HCFA”，那么我必须从表 Y 中提取一些数据. 就是那些类型的东西。我希望这会有所帮助。

Answer 1

在这种情况下，对存储过程再投一票。

您尝试建模的是一段非常具体的业务逻辑(“什么是声明”)，它需要在处理声明概念的所有应用程序中保持一致。

如果您只有一个应用程序，或者多个应用程序使用相同的中间件，您可以将其放在客户端代码中；然而，实践表明，数据库的生命周期往往比访问它们的软件要长。

您不希望最终导致冗余实现中的细微错误和极端情况导致不同的应用程序以略微不同的方式查看数据。干，等等。