数据库设计有助于使用不同的模式

时间:2009-04-13 16:19:32

标签: sql-server xml database-design sql-server-2000

我致力于为其核心服务使用一些复杂的基于大型机的计费软件的计费服务。我们设置了各种用于跟踪事物的代码:支付代码,提供商代码,注销代码等......每种类型的代码都有一组完全不同的数据项,用于控制代码的作用和它是如何表现的。

我的任务是构建一个新系统来跟踪对这些代码所做的更改。我们想知道是谁请求了哪些代码,审核,批准和实施的人员/时间,以及该代码的确切设置。当前进程仅跟踪两种不同类型的代码。该项目将为第三个项目添加即时支持,目标是还可以在以后轻松地将其他代码类型添加到同一个流程中。我的设计难题是每种代码类型都有一组不同的数据需要配置,具有不同的复杂性。所以我有几个选择:

  • 我可以给每个代码类型它自己的表格并独立构建它们。考虑到我们目前只关注三个代码,这将是最简单的。但是,这个概念已经失败,或者我不会首先构建一个新系统。它的弱点在于,在表示级别编写通用源代码以显示任何代码类型(甚至那些尚未实现的代码类型)的请求数据所涉及的代码并非易事。

  • 构建一个能够存储与每种代码类型相关联的数据点的数据库模式:不仅包括值,还包括它们的类型以及它们的显示方式(某种类型的枚举下拉列表)。我开始使用了一个不错的数据库模式,但它感觉不对:查询和维护过于复杂,最终需要一个自定义查询来查看每个代码类型的表格中的完整数据。

  • 将每个代码请求的数据点存储为xml。这极大地简化了数据库设计,并有望使构建接口变得更容易:只需为每种代码类型设置一个模式。然后使用代码验证对其架构的请求,将架构转换为显示窗口小部件并将实际请求项映射到显示器上。这个项目缺少的是如何处理模式的更改。

我的问题是:你会怎么做?我错过了任何大的设计选择吗?这些选择有任何其他优点/缺点吗?

我目前的倾向是使用xml选项。鉴于架构更新是预期的但非常罕见(每18个月可能少于一个代码类型),我应该构建它以假设架构永远不会更改,但是以后我可以轻松地添加对更改架构的支持吗?在SQL Server 2000中会是什么样子(我们正在转向SQL Server 2005,但是在这个项目应该完成之前就不会准备好了吗?)

[更新]:
我认为xml的一个原因是一些数据将是复杂的:嵌套/条件数据,枚举下拉列表等。但我真的不需要查询任何数据。所以我认为在xml架构中定义这些数据会更容易。

然而,le dorfier关于引入一项全新技术的观点非常接近国内。我们目前在任何地方使用非常少的xml。这种情况正在慢慢改变,但目前这看起来有点不合适。

我也不完全确定如何从模式构建输入表单,然后以优雅的方式将与该模式匹配的记录合并到表单中。仅存储部分完成的记录将非常普遍,因此我不想从记录本身构建表单。不过,这是一个针对不同问题的主题。

基于迄今为止的所有评论,Xml仍然是主要候选人。单独的表格可能同样好或更好,但我觉得我的经理会发现与我们目前正在做的事情相比,这些表格并不完全不同或通用。

3 个答案:

答案 0 :(得分:4)

对于复杂,细致的问题,没有简单,通用的解决方案。您不能同时拥有简单存储和简单的应用程序逻辑。数据库结构必须复杂,否则您的应用程序必须很复杂,因为它会解释数据。

我在“product table, many kind of product, each product have many parameters”中概述了这个一般问题的五种解决方案。

根据您的情况,我倾向于具体表继承序列化LOB (XML解决方案)。

XML可能是一个很好的解决方案的原因是:

  • 您不需要使用SQL来挑选单个字段;你总是要展示整个表格。
  • 您的XML可以为数据类型,用户界面控制等字段添加注释。

但是当然你需要添加代码来解析和验证XML。您应该使用XML模式来帮助解决这个问题。在这种情况下,您只需将一种技术替换为另一种(XML模式)来强制执行数据组织(RDBMS)。

您也可以使用RDF解决方案而不是RDBMS。在RDF中,元数据是可查询和可扩展的,您可以使用“事实”对实体进行建模。例如:

  • 付款代码XYZ包含属性TradeCredit(Net-30,Net-60等)
  • 属性TradeCredit的类型为CalendarInterval
  • 类型CalendarInterval显示为下拉列表
  • ..等等

重新评论:是的,我对任何使用XML的解决方案都很谨慎。解释Jamie Zawinski

  

有些人在遇到问题时会想“我知道,我会使用XML”。现在他们有两个问题。

另一个解决方案是发明一点Domain-Specific Language来描述你的表格。用它来生成用户界面。然后使用数据库 only 来存储表单数据实例的值。

答案 1 :(得分:2)

为什么你说“这个概念已经失败,或者我不会首先构建一个新系统”?是因为你怀疑必须有一个共同处理它们的方案吗?

否则我会说继续现有的理念,并建立额外的表格。至少它将共享现有模式并在这方面保持一致性。

答案 2 :(得分:0)

对“广义专用关系建模”进行网络搜索。您将找到有关如何设置存储每种代码属性的表以及所有代码共有的属性的文章。

如果您对对象建模感兴趣,只需搜索“通用专用对象建模”。

相关问题