SQL Server 2005：按视图包装表 - 优点和缺点

Question

背景

我正在研究一个传统的小型企业自动化系统（库存，销售，采购等），它有一个由SQL Server 2005托管的单个数据库和一堆客户端应用程序。 主客户端（由所有用户使用）是MS Access 2003应用程序（ADP），其他客户端包括各种VB / VBA应用程序，如Excel加载项和命令行实用程序。

除了60个左右的表（大多数是3NF）之外，数据库还包含大约200个视图，大约170个UDF（主要是标量和表值内联的），以及大约50个存储过程。 正如您可能已经猜到的那样，所谓的“业务逻辑”的某些部分被封装在大量的T-SQL代码中（因此被所有客户端共享）。

总的来说，系统的代码（包括T-SQL代码）组织得不是很好，可以说是非常重构的。 特别是，大多数表的模式都适用于所有类型的重构，小型（如列重命名）和大型（如规范化）。

FWIW，我有很长很好的应用程序开发经验（C / C ++，Java，VB和诸如此类的东西），但我不是DBA。 所以，如果这个问题看起来很愚蠢，现在你知道为什么会这样。 :-)

题

在考虑重构所有这些混乱时（当然是以和平方式），我想出了以下想法：

1. 对于每个表，创建一个“包装器”视图，其中（a）具有该表具有的所有列; （b）在某些情况下，根据表的“实际”列有一些额外的计算列。

   这种附加计算列的典型（尽管是简单的）示例是从产品的常规价格和折扣得到的产品的销售价格。

2. 重新组织所有代码（T-SQL和VB / VBA客户端代码），以便只有“包装器”视图直接引用表。

   因此，例如，即使应用程序或存储过程需要从表中插入/更新/删除记录，它们也会针对相应的“表包装器”视图执行此操作，而不是直接针对表。

因此，基本上这是关于通过视图将所有表与系统的其余部分隔离开来 。

这种方法似乎提供了很多好处，特别是从可维护性的角度来看。 例如：

• 当要重命名表列时，可以在不重写所有受影响的客户端代码的情况下完成。

• 实现派生属性更容易（比使用计算列更容易）。

• 您可以有效地为列名称添加别名。

显然，所有这些好处都必须有一些代价，但我不确定我是否看到了潜伏在那里的所有渔获物。

有人在实践中尝试过这种方法吗？ 有哪些主要缺陷？

一个明显的缺点是维护“包装”视图与其相应表同步的成本（表中的新列也必须添加到视图中;从表中删除的列也必须从视图中删除;等等）。 但是这个价格似乎很小，而且可以使整个代码库更具弹性。

有没有人知道任何其他更强的缺点？

例如，使用所有这些“包装”视图而不是表格很可能会对性能产生一些不利影响，但这种影响是否足以让人担心呢？ 此外，在使用ADODB时，即使只基于少数连接表，也很容易获得不可更新的记录集。 那么，“包装”观点是否会使事情变得更糟？ 等等等等...

任何评论（特别是共享的实际经验）将不胜感激。

谢谢！

---

PS我接下来讨论了“包装”视图的想法：

大观神话

该文章建议避免上述方法。 但是......我在文章中没有看到任何反对这个想法的充分理由。 恰恰相反，在创建视图的充分理由列表中，几乎每个项目都是为什么为每个表创建一个“包装”视图（特别是在遗留系统中，作为重构过程的一部分）如此诱人的原因）。

这篇文章真的很古老（1999），所以无论什么理由都好，那么现在可能已经不再好了（反之亦然）。 使用最新版本的SQL Server和MS Access，听到最近考虑过甚至尝试过这个想法的人真的很有意思......

Answer 1

在设计数据库时，我更喜欢以下内容：

• 没有代码的直接表访问（但是从存储过程和视图和函数可以）
• 包含所有列的每个表的基本视图
• 每个表的扩展视图，包括查找列（类型，状态等）
• 所有更新的存储过程
• 任何复杂查询的函数

这允许DBA直接使用表（添加列，清理内容，注入数据等）而不会干扰代码库，并且它使代码库与对表所做的任何更改（临时或其他）隔离开来

以这种方式做事可能会受到性能损失，但到目前为止它们并没有显着的重要性 - 绝缘层的好处已经多次挽救了生命

Answer 2

您不会注意到对一个表视图的性能影响; 在使用这些视图为任何代码构建执行计划时，SQL Server将使用基础表。 我建议您对这些视图进行模式绑定，以避免在不更改视图的情况下意外更改基础表（想想下一个可怜的人）。

要重命名表列时

根据我的经验，这很少发生。 添加列，删除列，更改索引和更改数据类型是您将运行的常用alter table脚本。

实现派生属性更容易（比使用计算列更容易）。

我会对此提出质疑。 将计算放在列定义中并将其放在视图定义中有什么区别？ 此外，您会看到将其移动到视图而不是计算列的性能损失。 唯一真正的优点是在视图中更改计算比通过更改表更容易（由于索引和数据页）。

您可以有效地为列名称添加别名。

这是获得观点的真正原因; 别名表和列，以及组合多个表。 在我过去的几个工作中的最佳实践是使用我需要对数据进行非规范化的视图（查找等等，正如您已经指出的那样）。

像往常一样，对DBA问题的最真实的回答是“它取决于” - 关于你的情况，技能组等。在你的情况下，重构“一切”将打破所有的应用程序。 如果您确实正确修复了基表，则不需要您尝试从视图中获取的间接，并且只会将架构维护的两倍用于将来的更改。 我会说跳过包装器视图，修复表和存储过程（它们提供了足够的信息隐藏），你会没事的。

Answer 3

我同意Steven的评论 -主要是因为您正在使用Access。 在重新设计此数据库时，保持Access的优缺点非常重要。 我一直在那里，使用Access前端/ SQL Server后端完成了这项工作（尽管它不是ADP项目）。

我想补充说，视图很好地确保数据不会在项目中的Access表单之外更改。 缺点是所有更新都需要存储过程 - 如果您还没有这些更新，则必须创建它们。