Questions tagged «computed-column»

计算列是代表对给定表中包含的其他列执行的计算或操作的列。在某些产品中称为生成的列或虚拟列。

2
有没有一种方法可以防止计算列中的标量UDF抑制并行性？
关于SQL Server 中标量UDF的危害，已经写了很多文章。随意搜索将返回大量结果。 但是，在某些地方，标量UDF是唯一的选择。 例如：在处理XML时：XQuery不能用作计算列定义。Microsoft记录的一个选项是使用Scalar UDF将XQuery封装在Scalar UDF中，然后在计算列中使用它。 这会产生各种影响，并有一些解决方法。 查询表时逐行执行 强制对表的所有查询顺序运行 您可以通过模式绑定该函数并持久保存计算的列或对其进行索引来解决逐行执行的问题。即使没有引用标量UDF，这两种方法都无法防止查询的强制序列化。 有已知的方法吗？
3
持久计算列上的索引需要键查找才能获取计算表达式中的列
此问题是从Stack Overflow 迁移而来的，因为可以在Database Administrators Stack Exchange上回答。 迁移 6年前。 我在表上有一个持久的计算列，该表只是由串联的列组成，例如 CREATE TABLE dbo.T ( ID INT IDENTITY(1, 1) NOT NULL CONSTRAINT PK_T_ID PRIMARY KEY, A VARCHAR(20) NOT NULL, B VARCHAR(20) NOT NULL, C VARCHAR(20) NOT NULL, D DATE NULL, E VARCHAR(20) NULL, Comp AS A + '-' + B + '-' …
5
无法在计算列上创建过滤索引
在我的上一个问题中，在向表中添加新的计算列时禁用锁升级是个好主意吗？，我正在创建一个计算列： ALTER TABLE dbo.tblBGiftVoucherItem ADD isUsGift AS CAST ( ISNULL( CASE WHEN sintMarketID = 2 AND strType = 'CARD' AND strTier1 LIKE 'GG%' THEN 1 ELSE 0 END , 0) AS BIT ) PERSISTED; 计算所得的列是PERSISTED，并且根据computed_column_definition（Transact-SQL）： 坚持 指定数据库引擎将物理地将计算出的值存储在表中，并在更新计算出的列所依赖的任何其他列时更新这些值。将计算列标记为PERSISTED允许在确定的但不精确的计算列上创建索引。有关更多信息，请参见计算列上的索引。任何用作分区表分区列的计算列都必须显式标记为PERSISTED。当指定PERSISTED时，computed_column_expression必须是确定性的。 但是，当我尝试在列上创建索引时，出现以下错误： CREATE INDEX FIX_tblBGiftVoucherItem_incl ON dbo.tblBGiftVoucherItem (strItemNo) INCLUDE (strTier3) WHERE isUsGift = 1; …
2
SQL Server用与定义不匹配的数据填充PERSISTED列是否合法？
我正在跟踪有关计算列中的奇怪值的问题PERSISTED。那里的答案使人对这种行为的产生方式有一些猜测。 我在问以下问题：这不是一个彻底的错误吗？是否PERSISTED允许列以这种方式运行？ DECLARE @test TABLE ( Col1 INT, Contains2 AS CASE WHEN 2 IN (Col1) THEN 1 ELSE 0 END PERSISTED) --depends on Col1 INSERT INTO @test (Col1) VALUES (ABS(CHECKSUM(NEWID()) % 5)), (ABS(CHECKSUM(NEWID()) % 5)), (ABS(CHECKSUM(NEWID()) % 5)), (ABS(CHECKSUM(NEWID()) % 5)), (ABS(CHECKSUM(NEWID()) % 5)) SELECT * FROM @test --shows impossible …
4
PostgreSQL：生成的列
PostgreSQL支持生成的列吗？也称为虚拟列。我不是在谈论IDENTITY专栏。 我找不到有关此卓越功能的任何信息，但我知道它在SQL Server以及最新版本的MariaDB和MySQL中都可用。 在SQL：2003标准中提到了该功能，并且在2006年左右的PostgreSQL论坛上进行了一些讨论，但是我对此没有实质性的了解。 关于SO有一些讨论，但是现在讨论已经很久了，所以它可能已经过时了。
2
不可搜索的持久化计算列上的索引
我有Address一个名为的表，该表具有一个称为的持久计算列Hashkey。该列是确定性的，但不精确。它具有不可搜索的唯一索引。如果运行此查询，则返回主键： SELECT @ADDRESSID= ISNULL(AddressId,0) FROM dbo.[Address] WHERE HashKey = @HashKey 我得到这个计划： 如果我强制索引，我会得到更糟糕的计划： 如果我尝试同时使用索引和查找，则会收到错误消息： 由于此查询中定义的提示，查询处理器无法生成查询计划。重新提交查询而不指定任何提示，也无需使用SET FORCEPLAN 这仅仅是因为它不精确吗？我以为如果坚持下去没关系吗？ 有没有一种方法可以使该索引可查询而不将其设为非计算列？ 有人在此链接到任何信息吗？ 我无法发布实际的表创建，但是这是一个具有相同问题的测试表： drop TABLE [dbo].[Test] CREATE TABLE [dbo].[Test] ( [test] [VARCHAR](100) NULL, [TestGeocode] [geography] NULL, [Hashkey] AS CAST( ( hashbytes ('SHA', ( RIGHT(REPLICATE(' ', (100)) + isnull([test], ''), ( 100 )) ) + …
2
为什么在视图中将NOT NULL计算列视为可为空？
我有一张桌子： CREATE TABLE [dbo].[Realty]( [Id] [int] IDENTITY(1,1) NOT NULL, [RankingBonus] [int] NOT NULL, [Ranking] AS ([Id]+[RankingBonus]) PERSISTED NOT NULL .... ) 和一个视图： CREATE View [dbo].[FilteredRealty] AS SELECT realty.Id as realtyId, ... COALESCE(realty.Wgs84X, ruian_cobce.Wgs84X, ruian_obec.Wgs84X) as Wgs84X, COALESCE(realty.Wgs84Y, ruian_cobce.Wgs84Y, ruian_obec.Wgs84Y) as Wgs84Y, realty.Ranking, ... FROM realty JOIN Category ON realty.CategoryId = …
2
未使用计算列索引
我想根据两列是否相等来进行快速查找。我试图使用带有索引的计算列，但是SQL Server似乎没有使用它。如果仅使用带有索引的静态填充的位列，则会得到预期的索引查找。 似乎还有其他类似的问题，但是没有一个问题集中在为什么不使用索引上。 测试表： CREATE TABLE dbo.Diffs ( Id int NOT NULL IDENTITY (1, 1), DataA int NULL, DataB int NULL, DiffPersisted AS isnull(convert(bit, case when [DataA] is null and [DataB] is not null then 1 when [DataA] <> [DataB] then 1 else 0 end), 0) PERSISTED , DiffComp AS …
3
在非持久计算列SQL Server上创建非聚集索引
我正在努力寻找有关SQL Server如何实际存储非持久计算列的任何文档。 请看以下示例： --SCHEMA CREATE TABLE dbo.Invoice ( InvoiceID INT IDENTITY(1, 1) PRIMARY KEY, CustomerID INT FOREIGN KEY REFERENCES dbo.Customer(CustomerID), InvoiceStatus NVARCHAR(50) NOT NULL, InvoiceStatusID AS CASE InvoiceStatus WHEN 'Sent' THEN 1 WHEN 'Complete' THEN 2 WHEN 'Received' THEN 3 END ) GO --INDEX CREATE NONCLUSTERED INDEX IX_Invoice ON Invoice …
1
使用COALESCE将主键从IDENTITY更改为持久计算列
为了使应用程序与整体数据库脱钩，我们尝试将各种表的INT IDENTITY列更改为使用COALESCE的PERSISTED计算列。基本上，我们需要分离的应用程序能够为许多应用程序之间共享的通用数据更新数据库，同时仍允许现有应用程序在这些表中创建数据而无需修改代码或过程。 因此，从本质上讲，我们已经脱离了的列定义； PkId INT IDENTITY(1,1) PRIMARY KEY 至; PkId AS AS COALESCE(old_id, external_id, new_id) PERSISTED NOT NULL, old_id INT NULL, -- Values here are from existing records of PkId before table change external_id INT NULL, new_id INT IDENTITY(2000000,1) NOT NULL 在所有情况下，PkId也是主键，在除一种情况以外的所有情况下，它都是聚集的。所有表都具有与以前相同的外键和索引。本质上，新格式允许由解耦的应用程序提供PkId（作为external_id），但也允许PkId作为IDENTITY列值，因此允许通过使用SCOPE_IDENTITY和@@ IDENTITY依赖于IDENTITY列的现有代码照常工作。 我们遇到的问题是，我们遇到了一些查询，这些查询过​​去可以在可接受的时间内运行，现在已经完全崩溃了。这些查询使用的生成查询计划与以前不同。 鉴于新列是PRIMARY KEY，数据类型与以前相同，并且为PERSISTED，因此我希望查询和查询计划的行为与之前相同。就SQL Server如何生成执行计划而言，COMPUTED PERSISTED INT PkId是否应在本质上与显式INT定义具有相同的行为？您还可以看到这种方法还有其他可能的问题吗？ …
5
自助加入的替代方法
我在这里提出了一个问题：https : //stackoverflow.com/questions/43807566/how-to-divide-two-values-from-the-same-column-but-at-different-rows 关于从同一表，同一列，不同行划分值的问题。现在，我遇到的问题是，我有更多的分子和分母（具有不同的uns）。仍然是self join解决这一问题在Postgres或有更好的解决方案的好办法？ 例： | postcode | value | uns | |----------|-------|-----| | AA | 40 | 53 | | BB | 20 | 53 | | AA | 10 | 54 | | AA | 20 | 55 | | AA | 10 | 56 | | …
2
计算列无法保留，因为该列是不确定的
我知道这不是第一次提出此类问题。 但是，为什么在以下情况下创建的持久化计算列是“不确定的”。答案应该总是一样的，对不对？ CREATE TABLE dbo.test (Id INT, EventTime DATETIME NULL, PosixTime INT NOT NULL) GO DECLARE @EventTime DATETIME = '20181001 12:00:00' DECLARE @GPSTime INT = DATEDIFF(SECOND, '19700101', @EventTime) INSERT INTO dbo.Test(Id, EventTime, PosixTime) VALUES (1, @EventTime, @GPSTime) , (2, NULL, @GPSTime) GO SELECT * FROM dbo.test GO ALTER TABLE dbo.test …
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.