คอลัมน์ตัวตนหรือ UDF ที่สร้างรหัสเฉพาะอย่างชัดเจน?

ผมอยู่ในช่วงกลางของการอภิปรายเกี่ยวกับว่ามันจะดีกว่าที่จะทำให้PRIMARY KEYออกมาจากคอลัมน์ประจำตัวของเราออกจาก UDF ที่ชัดเจนสร้างรหัสที่ไม่ซ้ำกัน

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

การใช้งานแบบใดที่เหมาะสมกว่า

เพื่อนร่วมงานของคุณเป็นคนงี่เง่า

โซลูชันจะไม่สามารถปรับขนาดได้ แต่ UDF จะไม่ทำงานพร้อมกัน ( เหตุผลเดียวกับสิ่งนี้ ) และคุณจัดการกับส่วนแทรกแบบหลายแถวได้อย่างไร: สิ่งนี้จะต้องมีการเรียก UDF ต่อแถว

และการโยกย้ายไปยัง RDBMS อื่นไม่ได้เกิดขึ้นบ่อยครั้งในชีวิตจริง ... คุณอาจไม่ใช้ SQL Server ในตอนนี้และใช้ลำดับบน Oracle และหวังว่าคุณจะไม่ย้ายออกไป

แก้ไข:

สถานะการอัปเดตของคุณระบุว่าการย้ายข้อมูลมีไว้เพื่อรีเฟรชฐานข้อมูลที่ไม่ใช่การผลิต

ในกรณีนี้คุณจะข้ามคอลัมน์ข้อมูลประจำตัวเมื่อรีเฟรช คุณไม่ประนีประนอมการใช้งานของคุณเพื่อทำให้การโหลดที่ไม่ใช่ผลิตภัณฑ์ง่ายขึ้น หรือใช้ตาราง temp เพื่อติดตามการเปลี่ยนแปลงค่าตัวตน

หรือใช้กระบวนการ: เรารีเฟรชระบบทดสอบของเราทุกคืนจากการผลิตซึ่งหลีกเลี่ยงปัญหาทั้งหมด (และทำให้มั่นใจว่าการสำรองข้อมูลกระทุ้งของเราสามารถกู้คืนได้เช่นกัน)

ใช้ค่าตัวตน การสร้างตารางลำดับและค่าลำดับของคุณจะใช้เวลามากและทำให้เกิดการล็อคและบล็อกจำนวนมากในขณะที่พยายามสร้างตัวเลข

มีข้อมูลประจำตัวด้วยเหตุผลใช้

เมื่อ SQL Denali ออกมามันจะสนับสนุนลำดับซึ่งจะมีประสิทธิภาพมากกว่าเอกลักษณ์ แต่คุณไม่สามารถสร้างสิ่งที่มีประสิทธิภาพมากขึ้นด้วยตัวคุณเอง

สำหรับการย้ายระเบียนจากสภาพแวดล้อมหนึ่งไปยังอีกสภาพแวดล้อมหนึ่งให้เปิด IDENTITY_INSERT เมื่อทำการแทรกหรือทำเครื่องหมายใน SSIS

คอลัมน์ตัวตนฟังดูดีสำหรับฉัน ฉันไม่แน่ใจว่าฉันทำตามตรรกะเกี่ยวกับสาเหตุที่ทำให้การย้ายข้อมูลระหว่างเซิร์ฟเวอร์เป็นเรื่องยาก

หากคุณต้องการให้แต่ละแถวมีตัวตนที่ไม่ซ้ำกันทั่วโลกคุณสามารถใช้ UUID ได้ แต่ฉันจะไม่ทำอย่างนั้นจนกว่าคุณจะแน่ใจว่ามีความเป็นเอกลักษณ์ระดับโลกที่จำเป็น - โดยปกติแล้วไม่ใช่ การใช้ UUID เป็นรหัสจะลดประสิทธิภาพเพิ่มความต้องการพื้นที่ดิสก์และทำให้การดีบักยากขึ้นเนื่องจากความยาวของการจดจำ UUID นั้นยากบอกให้คนอื่นทราบทางโทรศัพท์หรือเขียนลงบนกระดาษโดยไม่มีข้อผิดพลาด

สำหรับรหัสตัวเลขอย่างง่ายเพียงแค่ไปกับตัวตนและลืมปัญหาทั้งหมดของการสร้างด้วยตนเอง

คุณสามารถสร้าง "super table" ที่ใช้ข้อมูลประจำตัวเป็น PK และมีคอลัมน์ประเภทและข้อมูลอื่น ๆ เมื่อคุณต้องการ ID ใหม่ (สมมติว่าคุณหมายถึง IDS ที่ไม่ซ้ำกันในตารางที่แตกต่างกัน) เพียงแค่แทรกลงในตารางนี้แล้วคว้าSCOPE_IDENTITY()และจากนั้นแทรกลงในตารางจริงที่คุณต้องการ

โดยทั่วไปคุณสร้างตาราง: MasterID ที่มี identity PK เมื่อคุณต้องการแทรกแถวใน Table1 ของคุณINSERT INTO MasterIDsและรับ identity ที่สร้างขึ้นโดยแถวนั้นโดยใช้SCOPE_IDENTITY()แล้วแทรกลงในTable1โดยใช้ค่านั้นเป็น PK

Table1จะมี PK ที่ไม่ระบุตัวตน คุณจะทำกระบวนการเดียวกันเพื่อแทรกลงใน Table2 ฯลฯ ให้ SQL Server จัดการค่าข้อมูลประจำตัวในตารางMasterIDซึ่งคุณสามารถใช้ในตารางอื่นของคุณได้ MasterIDอาจมีตารางอื่น ๆ เช่นชนิด (เพื่อให้คุณสามารถทราบว่าตารางใด Table1 หรือ Table2 ฯลฯ ใช้ค่าเอกลักษณ์นั้น

ตราบใดที่คุณกำลังใช้ข้อ จำกัด ของคีย์ต่างประเทศอย่างถูกต้อง (เรียงซ้อนอัปเดต ฯลฯ ) คุณก็จะสามารถใช้ฟิลด์ข้อมูลประจำตัวได้ ฉันไม่เห็นข้อได้เปรียบจากโซลูชันอื่นในกรณีนี้

มีการสร้างตัวตนให้เหมาะกับสถานการณ์ของคุณ คุณมีเครื่องมือเช่นการจำลองแบบสำหรับการแลกเปลี่ยนข้อมูลเซิร์ฟเวอร์ / สภาพแวดล้อมที่รวมเข้าด้วยกัน

ฉันเพิ่งเสร็จงานที่ฉันได้แทนที่identityคอลัมน์SQL Server ด้วยintฟิลด์ปกติและควบคุมการจัดสรรรหัสด้วยตนเอง

ฉันได้เห็นการเพิ่มประสิทธิภาพที่น่าประทับใจ ไม่เหมือนกับ OP ฉันไม่มี UDF เพื่อสร้างรหัส แต่หลักการก็เหมือนกันมาก: มีส่วนหนึ่งของซอฟต์แวร์ที่เก็บรหัสประจำตัว เมื่อพวกเขาวิ่งออกไปจะได้รับชุดอื่นโดยการสอบถามฐานข้อมูลสำหรับถัดไปต่ำมูลค่าและเพิ่มขึ้นนี้ต่อไปสูง

สิ่งนี้ช่วยให้เราสามารถสร้างรหัสและเชื่อมโยงเอนทิตี้ทั้งหมดนอกธุรกรรมใน ORM ของเราก่อนที่เราจะส่งแบตช์ไปยังฐานข้อมูลและยังส่งแบทช์ที่ใหญ่กว่าโดยไม่มีการปัดเศษพิเศษเพื่อรับข้อมูลประจำตัว

ในตาราง id เรามีมากกว่าหนึ่งแถวทำให้เราสามารถใช้ช่วงเฉพาะได้หากต้องการ เช่นสำหรับการนำบล็อกที่ถูกลบและรหัสเชิงลบกลับมาใช้ใหม่

ฉันใช้ข้อมูลประจำตัวมาหลายปีแล้วและกำลังพิจารณาอย่างจริงจังว่าจะเปลี่ยนหมายเลขประจำตัวด้วย UNIQUEIDENTIFIER มันเป็นฝันร้ายเมื่อคุณต้องการเปลี่ยนประเภทข้อมูลถ้ามีคนออกแบบให้เป็นฐานข้อมูลขนาดกะทัดรัดและฝันร้ายถ้าคุณต้องการเพิ่มข้อมูลประจำตัวในคอลัมน์เช่นกันคุณไม่สามารถอัปเดตคอลัมน์ข้อมูลประจำตัวได้ ลองนึกภาพคุณใส่ int และฐานข้อมูลของคุณเติบโตเกินกว่า 2 พันล้านรายการฝันร้ายที่จะเปลี่ยน (พิจารณา FKs) อีกครั้ง! การเปลี่ยนแปลงอะไรก็ตามที่มีตัวตนเป็นฝันร้ายและไม่เป็นมิตรกับผู้อื่นเว้นแต่คุณจะใส่คำโต! UNIQUEIDENTIFIER vs Identity = ความสะดวกสบายและความทนทาน vs การปรับปรุงประสิทธิภาพที่เห็นได้ชัดเจน (อาจไม่เป็นมาตรฐาน)

อัปเดต: หลังจากที่ฉันเห็นสิ่งนี้แล้วฉันจะต้องพึ่งพา UNIQUEIDENTIFIER อย่างแน่นอน สิ่งนี้แสดงให้เห็นว่าไม่มีประโยชน์ที่แท้จริงของตัวตนที่ยิ่งใหญ่และเป็นประโยชน์สำหรับ UNIQUEIDENTIFIER! SQL Server เวอร์ชันต่างกันอาจมีผลลัพธ์ที่ต่างกัน มีเพียงแค่ความสวยงามในการมี ID ที่ไม่ซ้ำใครในทุกฐานข้อมูลและระบบ ย้ายคัดลอกแปลงข้อมูลตามที่คุณต้องการ! https://www.mssqltips.com/sqlservertip/5105/sql-server-performance-comparison-int-versus-guid/