不同模式的数据库设计帮助

我为一个计费服务工作,它的核心服务使用一些复杂的基于主机的计费软件。我们有各种各样的代码,我们建立了用于跟踪的东西:支付代码,供应商代码,注销代码,等等…每种类型的代码都有一组完全不同的数据项,这些数据项控制代码的作用和行为。

我的任务是建立一个新的系统来跟踪对这些代码所做的更改。我们想知道谁请求了什么代码,谁/什么时候审查、批准和实现了代码,以及该代码的确切设置是什么样子的。当前进程只跟踪两种不同类型的代码。此项目将立即添加对第三个进程的支持,其目标是使以后向同一进程中添加其他代码类型更加容易。我的设计难题是,每种代码类型都有不同的数据集,需要对其进行配置,这些数据集的复杂性也不尽相同。所以我有几个选择:

• 我可以给每个代码类型一个表,然后独立地构建它们。考虑到目前我只关心三个代码,这将是最简单的。然而,这个概念已经失败了,否则我不会首先建立一个新的系统。在表示层编写通用源代码以显示任何代码类型(甚至那些尚未实现的类型)的请求数据的代码并不简单,这一点也很薄弱。

• 构建一个能够存储与每种代码类型相关联的数据点的数据库模式:不仅是值,还有值的类型和显示方式(某种枚举的下拉列表)。我已经有了一个不错的数据库模式,但这感觉是错误的:查询和维护过于复杂,而且它最终需要一个自定义查询来查看每种代码类型的完整数据。

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

我的问题是:你会怎么做?我错过了什么大的设计选择吗?对这些选择还有其他的利弊吗?

我目前的倾向是使用xml选项。考虑到架构更新是预期的,但非常少见(每18个月可能少于一个代码类型),我是否应该构建它以假设架构从未更改,但这样以后可以轻松地添加对更改架构的支持?在sql server 2000中会是什么样子(我们将迁移到sql server 2005,但是在这个项目应该完成之后才准备好)?

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

然而,勒多菲尔关于引进一种全新技术的观点非常接近国内。我们目前在任何地方都很少使用XML。这种情况正在慢慢改变,但目前看来这有点不合时宜。

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

基于迄今为止的所有评论,xml仍然是领先的候选对象。单独的表格可能是好的,也可能更好,但我觉得我的经理会认为,与我们目前的工作相比,这并没有什么不同或通用性。