SQLServer2005：按视图包装表-优缺点 背景

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

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

总的来说，系统的代码（包括T-SQL代码）组织得不是很好，可以说是很难重构。特别是，大多数表的模式需要各种重构，小重构（如列重命名）和大重构（如规范化）

FWIW，我有相当长的应用程序开发经验（C/C++、Java、VB等等），但我不是DBA。所以，如果你觉得这个问题很傻，现在你知道为什么了。：-）

问题: 在考虑重构所有这些乱七八糟的东西时（当然是以和平的方式），我想到了以下想法：

对于每个表，创建一个“包装器”视图，该视图（a）包含该表的所有列；和（b）在某些情况下，具有一些基于表的“实”列的额外计算列

这种额外计算列的一个典型（尽管过于简单）示例是从产品的常规价格和折扣中得出的产品销售价格

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

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

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

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

• 当要重命名表列时，无需一次重写所有受影响的客户端代码即可完成此操作

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

• 可以有效地使用列名的别名

显然，所有这些好处都有一定的代价，但我不确定我是否看到了所有潜在的渔获量

有人在实践中尝试过这种方法吗？主要的陷阱是什么

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

有人知道其他更严重的缺点吗

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

如有任何意见（特别是分享真实经验），将不胜感激

谢谢大家!

---

p.S.我在下面一篇讨论“包装器”视图的老文章中提到：

本文建议避免上述方法。但是在这篇文章中，我真的看不出有什么好的理由反对这个想法。恰恰相反，在创建视图的良好理由列表中，几乎每一项都是为每个表创建“包装器”视图的原因（特别是在遗留系统中，作为重构过程的一部分）

---

这篇文章真的很老（1999年），所以无论什么原因当时是好的，现在可能不再是好的（反之亦然）。如果最近有人考虑过甚至尝试过使用最新版本的SQL Server和MS Access来实现这一想法，那将非常有趣。

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

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

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

这样做可能会有性能方面的损失，但到目前为止，这些损失并不显著——隔热层的好处已经多次成为救生圈，我同意这一点——主要是因为您使用的是Access。在重新设计此数据库时，关注Access的优缺点非常重要。我曾经去过那里，用Access前端/SQL Server后端完成过（尽管它不是ADP项目）

---

我想补充一点，视图可以确保数据不会在项目中的访问表单之外发生更改。缺点是所有更新都需要存储过程——如果您还没有存储过程，那么也必须创建存储过程。

您不会注意到单表视图的任何性能影响；SQL服务器