具有视图的数据库

许多关系数据库引擎支持视图。视图可以充当一种虚拟表，并且使用它们有时可以极大地改善体系结构和系统的可测试性，但是当然可能要付出一定的代价。

常见的简单计算

当您要在系统其余部分中使用的表包含可能保留的数据时，可能会遇到这种情况，该数据不适合直接用于特定目的的消耗。

例如，在复式记帐系统中，总帐表可能会将预订金额保留为所有行中的正十进制数字，而金额的符号实际上是由保留了条目的贷方或借方的其他列确定的。

正是这样的事实，即预订值是以这样的拆分方式编码的，并且出于许多用途的目的，实际值需要在预订端的上下文中进行，因此需要做出一个简单的计算表达式，该表达式将应用于预订的每一行。基础表。包含基于金额和贷方或借方的新计算值的简单视图可能是理想的选择。曾经写过，后来在许多地方使用。可以想象，这里要付出的代价就是性能。数据库引擎需要对通过此视图检索的每一行应用所述计算，但是同样，这是对行本地数据执行的简单的符号更改表达式。

数据的简洁版本

表通常可以包含许多列，这些列用作行中描述的项目的属性。数据的特定用法不一定总是需要所有这些列。视图可以在这里帮助选择仅特定使用场景和首选列顺序所需的列。

从宽表检查数据时，很难清楚地了解其中的内容。如果表中有一百列，而您唯一需要的列是位置1、89、16和74的列，并且您希望它们按该顺序排列，因为它们最重要，再加上一些简单的计算列和其他几列都不是那么重要非常重要，但对于这种情况仍然有用。

我更喜欢这样写视图-首先将重要的列（或计算的表达式）并按顺序排列好，然后再添加一些有用但非必要的列，仅此而已。

也有警告。例如，您正在使用SQL Server并创建一个没有SchemaBinding属性的视图。在更改基础表的定义之前，一切工作正常，例如在该表的列列表中间插入新列。突然，您的视图开始输出一些奇怪的数据，例如“先生”。或“太太” 在fist_name列中。创建视图时，引擎实际上使用视图的元数据保存该视图的元数据，该视图的访问列由该列的索引而不是该列的名称引用。某些随后的表修改以后可能会导致此问题。您可以通过应用SchemaBinding属性来保护自己免受这种情况的影响，但是，当真正需要更改基础表时，也会导致管理问题，因为它迫使您在修改表之前删除整个架构绑定视图集，并在以后重新创建它们（如果依赖于另一个）。使用该属性的其他限制也适用。但是话又说回来，通过在列列表的中间插入列来修改表并不是轻量级的操作，应该很少发生。我宁愿不使用SchemaBinding属性，而使用脚本通过使用系统过程sp_refreshview自动刷新所有视图的内部元数据定义。也可能有一些警告：如果有人重命名，则某些版本的SQL Server可能会将视图定义还原为旧版本。也不适用于Azure云服务器版本。

组织代码

SQL Server引擎支持数据库中的架构作为逻辑单元，可以帮助组织对象和应用安全性。当我使用一个陌生的数据库并拥有创建新内容的权限时，我通常通常先创建“帮助”架构，然后开始在其中创建助手视图和其他对象。这背后的原理很简单–检查数据库模型需要花费时间，并且在您学习模型的各个部分时，将有趣的查询包装到视图中以帮助您更快地浏览数据并可能暴露模型中的某些异常要容易得多。或其中的数据。

想法还在于，这些帮助程序视图实际上只是–它们未在系统的其他部分中使用，并且没有任何依赖于它们的视图。您可以在学习新事实时对其进行编辑，或者如果发现它们无用，则可以将其完全删除。在这种视图中，您可以轻松地添加注释，其中包含有关如何从研究中选择有趣的案例的示例。当您或您的同事在很久以后重新查看这种观点并回想起为什么做某事的原因时，这可以使您记忆的速度更快。在您已经连接到的特定数据库的上下文中，无需搜索文件，即提供帮助。

使用视图的另一个示例是在数据库与调用客户端API和应用程序之间创建某种“接口”。这当然不是必需的，但是随着系统复杂性的增加，从数据库的原始表中进行抽象层将是有益的。您可以在“ api”或“ app”模式中放置视图，并同意您的同事在应用程序端使用这些模式。这种方法的一个好处是，无论是数据正确性还是检索性能，任何特定视图的可测试性都更加容易。随着数据量的增长，您可以测试这种视图的性能和执行计划，并可能发现需要添加或更改索引以帮助加快处理速度。

当然，这种方法也可能会有弊端，因为您将不得不管理另一层抽象并使它与系统的其他部分保持同步。