คำถามติดแท็ก computed-column

คอลัมน์จากการคำนวณคือคอลัมน์ที่แสดงถึงการคำนวณหรือการดำเนินการกับคอลัมน์อื่น ๆ ที่มีอยู่ในตารางที่กำหนด รู้จักกันในชื่อคอลัมน์ที่สร้างขึ้นหรือเสมือนในผลิตภัณฑ์บางอย่าง

2
มีวิธีการป้องกันไม่ให้ Scalar UDFs ในคอลัมน์ที่คำนวณได้จากการยับยั้งความเท่าเทียมกันหรือไม่?
มีการเขียนมากมายเกี่ยวกับภัยของ Scalar UDFใน SQL Server การค้นหาทั่วไปจะส่งคืนผลลัพธ์จำนวนมาก มีสถานที่บางแห่งที่ Scalar UDF เป็นตัวเลือกเท่านั้น เป็นตัวอย่าง: เมื่อจัดการกับ XML: XQuery ไม่สามารถใช้เป็นข้อกำหนดคอลัมน์ที่คำนวณได้ ทางเลือกหนึ่งที่มีการบันทึกโดย Microsoft คือการใช้Scalar UDFเพื่อแค็ปซูล XQuery ของคุณใน Scalar UDF จากนั้นใช้ในคอลัมน์ที่คำนวณ สิ่งนี้มีเอฟเฟกต์ต่าง ๆ และวิธีแก้ปัญหาบางอย่าง ดำเนินการทีละแถวเมื่อมีการสอบถามตาราง บังคับให้คิวรีทั้งหมดกับตารางทำงานแบบอนุกรม คุณสามารถหลีกเลี่ยงการประมวลผลแบบแถวต่อแถวได้โดยการกำหนดฟังก์ชันและคงคอลัมน์ที่คำนวณไว้หรือสร้างดัชนี ไม่มีวิธีใดที่สามารถป้องกันการบังคับให้ลำดับของเคียวรีที่กดปุ่มตารางแม้ว่าสเกลาร์ UDF ไม่ได้ถูกอ้างอิง มีวิธีที่รู้จักกันในการทำเช่นนั้น?

3
เมื่อใดที่คำนวณคอลัมน์
กำหนดค่าสำหรับคอลัมน์ที่คำนวณได้เมื่อใด เมื่อค่าถูกดึง? เมื่อมีการเปลี่ยนแปลงค่าหรือไม่ บางเวลาอื่น ๆ ฉันเดาว่านี่เป็นคำถามสามเณรเพราะฉันไม่พบสิ่งใดในการค้นหาของฉัน

3
ดัชนีบนคอลัมน์ที่คำนวณแล้วต้องการค้นหาคีย์เพื่อรับคอลัมน์ในนิพจน์ที่คำนวณ
คำถามนี้ถูกโยกย้ายจาก Stack Overflow เพราะสามารถตอบได้ใน Exchange 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 + '-' + …

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) : ยืนกราน ระบุว่า Database Engine จะจัดเก็บค่าที่คำนวณในร่างกายและอัพเดตค่าเมื่อคอลัมน์อื่น ๆ ที่คอลัมน์ที่คำนวณขึ้นอยู่นั้นถูกอัพเดต การทำเครื่องหมายคอลัมน์ที่คำนวณเป็น PERSISTED อนุญาตให้สร้างดัชนีบนคอลัมน์ที่คำนวณได้ซึ่งกำหนดไว้ แต่ไม่แม่นยำ สำหรับข้อมูลเพิ่มเติมดูดัชนีในคอลัมน์ที่คำนวณ …

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 …

4
PostgreSQL: คอลัมน์ที่สร้าง
PostgreSQL สนับสนุนคอลัมน์ที่สร้างขึ้นหรือไม่ ก็รู้ว่าเป็นคอลัมน์เสมือน ฉันกำลังไม่ได้พูดคุยเกี่ยวกับคอลัมน์IDENTITY ฉันไม่สามารถหาข้อมูลเกี่ยวกับคุณสมบัติที่น่าทึ่งนี้ได้ แต่ฉันรู้ว่ามันมีอยู่ใน SQL Server และใน MariaDB & MySQL เวอร์ชันล่าสุด คุณลักษณะดังกล่าวได้รับการกล่าวถึงในมาตรฐานSQL: 2003และมีการพูดคุยกันในฟอรัม PostgreSQL ประมาณปี 2549 แต่ฉันไม่พบสิ่งใดในเนื้อหา มีการอภิปรายเกี่ยวกับ 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(' ', …

2
เหตุใดคอลัมน์ที่คำนวณเป็นค่า 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 …

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 …

1
เปลี่ยนคีย์หลักจาก IDENTITY เป็นคอลัมน์ที่คำนวณแล้วโดยใช้ COALESCE
ในความพยายามที่จะแยกแอปพลิเคชันออกจากฐานข้อมูลเสาหินของเราเราได้พยายามเปลี่ยนคอลัมน์ INT IDENTITY ของตารางต่างๆให้เป็นคอลัมน์ที่คำนวณแบบ PERSISTED ที่ใช้ COALESCE โดยพื้นฐานแล้วเราต้องการแอปพลิเคชั่นแยกสองตัวที่ยังคงสามารถอัปเดตฐานข้อมูลสำหรับข้อมูลทั่วไปที่แชร์ในแอปพลิเคชันจำนวนมากในขณะที่ยังคงอนุญาตให้แอปพลิเคชันที่มีอยู่สร้างข้อมูลในตารางเหล่านี้โดยไม่ต้องใช้ โดยพื้นฐานแล้วเราได้ย้ายจากคำจำกัดความคอลัมน์ของ; 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 ยังเป็นคีย์หลักและในทุกกรณียกเว้นเพียงกรณีเดียวก็คือ …

5
ทางเลือกในการเข้าร่วมด้วยตนเอง
ฉันได้ถามคำถามที่นี่: /programming/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 | …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.