คำถามติดแท็ก identity

สร้างคอลัมน์ข้อมูลประจำตัวในตาราง คุณสมบัตินี้ใช้กับคำสั่ง CREATE TABLE และ ALTER TABLE Transact-SQL

1
เหตุใดจึงลบคุณสมบัติเอกลักษณ์ในคอลัมน์ไม่ได้รับการสนับสนุน
ฉันได้อ่านแล้วว่าหลังจาก SQL Server 2000 ความสามารถในการ "ยกเลิกการระบุตัวตน" คอลัมน์ข้อมูลประจำตัวจะถูกลบออก และนี่คือ "โดยการออกแบบ" (ไม่ใช่แค่คุณสมบัติที่ขาดหายไป) นี่คือตัวอย่างที่ผมพบในบล็อกหนึ่ง มันเกี่ยวข้องกับการปรับปรุงตารางระบบ (และความสามารถนั้นถูกลบหลังจาก SQL Server 2000) ฉันเข้าใจว่าการทำเช่นนี้ผ่านตารางระบบไม่ใช่ความคิดที่ดี ฉันแค่สงสัยว่าทำไมคุณสมบัติที่จะทำเช่นนี้ไม่ได้อยู่ที่อื่น การหลีกเลี่ยงสิ่งนี้จะทำให้ฉันต้องทำงานเป็นจำนวนมาก (การคัดลอกแถวหลายร้อยล้านแถวไปยังตารางใหม่ในสภาพแวดล้อมที่ไม่หยุดทำงาน) ดังนั้นฉันคิดว่าฉันจะถาม "ทำไม" มีอะไรเปลี่ยนแปลงใน SQL Server 2005 และรุ่นที่ใหม่กว่าซึ่งทำให้สิ่งนี้เลว หรือว่ามันแย่เสมอและไม่เพิ่งล็อค? "แนวปฏิบัติที่ดีที่สุด" (หรือหลักการที่คล้ายกัน) ใดที่จะถูกละเมิดโดยทำให้คอลัมน์ข้อมูลประจำตัวเป็นคอลัมน์ปกติอีกครั้ง - อัปเดตเพื่อตอบคำขอ "ทำไมฉันถึงทำแบบนี้": นี่เป็นบทสรุประดับสูงมาก: ฉันจะเริ่มเพิ่มพาร์ติชันในตารางของฉัน (เพื่อให้ฉันสามารถเก็บถาวร / ล้างข้อมูลเก่า) นั่นคือทั้งหมดที่ง่าย แต่บางครั้งฉันจำเป็นต้องย้ายระเบียนไปยังพาร์ติชันที่แตกต่างกันดังนั้นจึงไม่ถูกลบออก (เมื่อพาร์ติชันเกิดขึ้นสำหรับการเก็บถาวร / ลบ) (ฉันมีการแบ่งคอลัมน์เพิ่มขึ้น 2 เพื่อให้มีพื้นที่เสมอในการย้ายแถวไปยังพาร์ติชันอื่น) แต่ถ้าคอลัมน์การแบ่งเป็นคอลัมน์ข้อมูลส่วนตัวฉันต้องลบและใส่ค่าใหม่อีกครั้ง (ไม่มีทางที่จะอัพเดทค่าของคอลัมน์ข้อมูลประจำตัว) ซึ่งทำให้เกิดปัญหากับการจำลองแบบ …

8
คอลัมน์ตัวตนหรือ UDF ที่สร้างรหัสเฉพาะอย่างชัดเจน?
ผมอยู่ในช่วงกลางของการอภิปรายเกี่ยวกับว่ามันจะดีกว่าที่จะทำให้PRIMARY KEYออกมาจากคอลัมน์ประจำตัวของเราออกจาก UDF ที่ชัดเจนสร้างรหัสที่ไม่ซ้ำกัน ฉันโต้เถียงกับคอลัมน์ข้อมูลประจำตัว คู่ของฉันกำลังโต้เถียงในการสร้างค่าด้วยตนเองเขาอ้างว่า โดยใส่ UDF ลงในตารางอื่นที่เราสามารถมี UDF ได้ ล็อคทรัพยากร เพิ่มตาราง ID ด้วยหนึ่งฟิลด์ที่เรียกID_Valueโดย1 ใช้สิ่งนี้เป็นตัวระบุที่ไม่ซ้ำกันระดับโลก หรือมีตารางทำid+1เมื่อแทรก ง่ายกว่าที่จะย้ายข้อมูลระหว่างเซิร์ฟเวอร์และ / หรือสภาพแวดล้อมที่ไม่มีข้อ จำกัด ในการระบุ ย้ายจากฐานข้อมูลหนึ่งที่มีข้อมูลไปยังฐานข้อมูลอื่นที่คล้ายกันพร้อมให้บอกว่าการจัดเตรียมหรือข้อมูลจำลอง สำหรับการทดสอบที่ไม่ใช่การผลิตเราอาจต้องการดึงระเบียนทั้งหมดจากเมื่อวานนี้ลงไปยังการจัดเตรียมสำหรับการทดสอบ การใช้งานแบบใดที่เหมาะสมกว่า

1
IDENTITY_INSERT มีผลต่อการทำงานพร้อมกันอย่างไร
ฉันกำลังพยายามช่วยเหลือลูกค้าด้วยโปรแกรมเสริม SAP ของ บริษัท อื่นที่มีปัญหาการโพสต์และไม่ได้รับการสนับสนุน ภายใต้สถานการณ์บางอย่างมันจะเก็บถาวรและโพสต์ที่ไม่สมบูรณ์จากตารางคิวการโพสต์ไปยังตารางเก็บถาวรการโพสต์ ฉันต้องการย้ายผลลัพธ์ที่เก็บถาวรเหล่านี้กลับไปที่คิว ID ของคิวคือคอลัมน์ข้อมูลประจำตัวและฉันต้องการเก็บไว้เหมือนเดิม คำถามคือถ้าฉันทำ identity_insert on / insert / identity_insert off ฉันจะคาดหวังอะไรเกี่ยวกับการเกิดพร้อมกันกับกระบวนการที่สร้างรายการคิวและคาดว่าคอลัมน์ identity จะถูกสร้างขึ้นโดยอัตโนมัติ? พอยน์เตอร์ใด ๆ ในวิธีที่ดีที่สุดในการแสดงพฤติกรรมดังกล่าวจะได้รับการชื่นชมอย่างมากเช่นกัน

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