首页 > 代码库 > 作死的玩一下计算列
作死的玩一下计算列
有时候因为之间有关系，就使用到了计算列。所以我又做一下实验
先随便搞张表
Use tempdbGOIF OBJECT_ID(‘TestTR1‘) IS NOT NULL DROP TABLE TestTR1GOCREATE TABLE [dbo].[TestTR1]( [ID] [int] IDENTITY(1,1) NOT NULL, [ColName] [nvarchar](100) NULL, [timestamp] [timestamp] NOT NULL, [ColCal] AS (newid()),PRIMARY KEY CLUSTERED ( [ID] ASC))
然后就可以插入数据了，一看，发现执行多少次，计算列就得出多少次不一样的结果~
INSERT INTO dbo.TestTR1 ( ColName )VALUES ( N‘Col1‘ )SELECT * FROM dbo.TestTR1SELECT * FROM dbo.TestTR1
| ID | ColName | timestamp | ColCal | |
| 1 | 1 | Col1 | 0x000000000000A412 | D6C4F1E6-0C81-4667-A9C3-73FBAC895D29 |
| 2 | 1 | Col1 | 0x000000000000A412 | 32F1D090-070C-4A03-86C7-27A354553EFF |
那是因为计算列的定义使用了不确定性函数导致的，并且这种情况是不能为计算列添加索引的。如果应用到复制，那么复制的结果，也会出现不一致性。
所以如果要使用计算列，要小心这种情况
作死的玩一下计算列
声明：以上内容来自用户投稿及互联网公开渠道收集整理发布，本网站不拥有所有权，未作人工编辑处理，也不承担相关法律责任，若内容有误或涉及侵权可进行投诉： 投诉/举报 工作人员会在5个工作日内联系你，一经查实，本站将立刻删除涉嫌侵权内容。