什么时候计算列合适？

Question

我正在考虑在Microsoft SQL Server 2008中设计一个带有计算列的表.它将是一个简单的计算,如(ISNULL(colA,(0))+ ISNULL(colB,(0))) - 就像一个总计.我们的应用程序使用Entity Framework 4.

我并不完全熟悉计算列,所以我很好奇其他人在适合使用它们时必须说什么,而不是其它实现相同结果的机制,例如视图或计算的实体列.

我有什么理由不想在表中使用计算列吗？

如果我使用计算列,是否应该保留？我读过有关不同的表现效果持续使用,不持久,索引和非索引计算列在这里.鉴于我的计算看起来很简单,我倾向于说不应该坚持下去.

Answer 1

根据我的经验,当它们可以在其他地方使用时,它们是最有用/最合适的,例如索引或检查约束,这有时需要保留列(物理存储在表中).有关更多详细信息,请参阅计算列和在计算列上创建索引.

Answer 2

如果您的计算列未持久化,则每次访问时都会计算它,例如a SELECT.如果基于它的数据经常变化,那可能没问题.

如果数据不经常更改,例如,如果您有一个计算列将数字OrderID INT转换为人类可读ORD-0001234或类似的数据,那么肯定会使您的计算列保持不变- 在这种情况下,将计算并物理存储该值在磁盘上,对它的任何后续访问就像读取表上的任何其他列 - 不会一遍又一遍地重新计算.

我们还开始使用(并高度赞赏!)计算列从XML列中提取某些信息,并将它们作为单独的(持久的)列在表上显示.这使得查询这些项目的效率远远高于不断使用XQuery检索XML以检索信息的效率.对于这个用例,我认为持久计算列是加速查询的好方法!

Answer 3

计算列是一种业务规则，在客户端而不是在存储中实现它更合适。数据库用于存储/检索数据，而不是用于业务规则处理。它可以做某事这一事实并不意味着您应该这样做。你也可以自由地离开埃菲尔铁塔，但这将是一个糟糕的决定:)