回到关系型 数据 库理论创立者E. F. Codd的时代，一个普遍原理出现了：永远都不要保存能够被 计算 的（内容）。这一原理回避了这样一个问题，“我们应该在什么地方 计算 这个已经 计算 出来的结果呢？”那么缺省的答案是，“在前端应用程序里。” 想像一下一
回到关系型
数据库理论创立者E. F. Codd的时代，一个普遍原理出现了：永远都不要保存能够被
计算的（内容）。这一原理回避了这样一个问题，“我们应该在什么地方
计算这个已经
计算出来的结果呢？”那么缺省的答案是，“在前端应用程序里。”
想像一下一个含有SubTotal和TaxRate列的表格。根据这一原则，TaxAmount和Total这两个“列”应该是虚拟的。所以，要将它们作为查看表或者存储过程的一部分创建；或者，换种方法，让前端应用程序来生成它们，并把它们呈现给用户。
这个原则的一个替换方法叫做
计算数据列（computed column）。有了这种表示方法，你可以将
计算数据列
声明为CREATE TABLE
陈述式的一部分，尽管这可能会被发布给
数据库（不论是通过图形用户界面还是直接作为
数据定义语言的指令）。
现在让我们来假设有一个
数据库，它包含有对房屋粉刷工作的估价。忽略诸如房间里门窗数量这样的细节（并假设所有的墙都刷上相同的颜色）就会带来两个问题：我们要把天花板涂上相同的颜色吗（一般情况下，答案是“不会”）；我们要涂几层（一般情况下，答案是“两层”）？
如果没有
计算数据列的话，我们就没有更好的办法来处理这些问题，这样就只有把这些结果的
计算推给前端应用程序。而有了
计算数据列，我们就可以把方程式嵌入到
数据库里，创建一个虚拟的
数据列，供任何前端使用。
你可以用下面这个
陈述式来创建表格：
CREATE TABLE [TestComputedColumns] (
[PK] [int] IDENTITY (1, 1) NOT NULL ,
[Length] [int] NOT NULL ,
[Width] [int] NOT NULL ,
[Height] [int] NOT NULL ,
[Coats] [int] NOT NULL CONSTRAINT [DF_TestComputedColumns_Coats] DEFAULT
(2),
[IncludeCeiling] [bit] NOT NULL CONSTRAINT
[DF_TestComputedColumns_IncludeCeiling] DEFAULT (0),
[Area] AS ((2 * ([Height] * [Length] + [Height] * [Width]) + [Length] *
[Width] * [IncludeCeiling]) * [Coats]),
CONSTRAINT [PK_TestComputedColumns] PRIMARY KEY
CLUSTERED
(
[PK]
)
ON [PRIMARY]
) ON [PRIMARY]
GO
你可以使用前端，插入一些
数据行，看看它是如何工作的。例如，使用Access 2000+创建一个指向你
数据库的访问
数据工程（Access Data Project，ADP），选择表格，然后创建一个AutoForm。输入一两个
数据行，然后通过你的输入翻回到前面；你会看到
计算数据列得到了正确的值。
