PK เป็น ROWGUIDCOL หรือใช้คอลัมน์ rowguid แยกต่างหาก


9

มีการถกเถียงกันยาว ๆ ที่นี่ดังนั้นฉันอยากได้ยินความคิดเห็นอื่น ๆ

ฉันมีตารางจำนวนมากที่มี PK เอกลักษณ์เฉพาะกลุ่ม ไม่ว่าจะเป็นความคิดที่ดีนอกขอบเขตที่นี่ (และจะไม่เปลี่ยนแปลงตลอดเวลาในไม่ช้า)

ตอนนี้ฐานข้อมูลจะต้องถูกเผยแพร่และ DEV กำลังสนับสนุนการใช้คอลัมน์ rowguid แยกต่างหากแทนที่จะทำเครื่องหมาย PK ที่มีอยู่เป็น ROWGUIDCOL

โดยพื้นฐานแล้วพวกเขาบอกว่าแอปพลิเคชันไม่ควรนำสิ่งที่ใช้ในการจำลองแบบโดเมนมาใช้เท่านั้น (เป็นเพียง "สิ่ง DBA" สำหรับพวกเขา)

จากมุมมองด้านประสิทธิภาพฉันไม่เห็นเหตุผลว่าทำไมฉันควรเพิ่มคอลัมน์ใหม่เพื่อทำสิ่งที่ฉันสามารถทำได้ด้วยคอลัมน์ที่มีอยู่ นอกจากนี้เนื่องจากเป็นเพียง "ข้อมูล DBA" ทำไมไม่ให้ DBA เลือก

ฉันเข้าใจประเด็นของ DEV แล้ว แต่ฉันก็ยังไม่เห็นด้วย

คิด?

แก้ไข:ฉันแค่ต้องการเพิ่มว่าฉันอยู่ในชนกลุ่มน้อยในการอภิปรายนี้และ DEVs ตั้งคำถามของฉันคือคนที่ฉันเคารพและเชื่อถือ นี่คือเหตุผลที่ฉันหันไปถามความคิดเห็น
ฉันอาจจะพลาดบางสิ่งบางอย่างและอาจเข้าใจผิดจุดของพวกเขา


มีโอกาสที่ค่าพีเคอาจจำเป็นต้องเปลี่ยนแปลงในอนาคตหรือไม่?
Robert L Davis

ไม่ไม่ได้จริงๆ มันเป็นกุญแจแทนที่ดังนั้นแอปไม่ได้ทำอะไรมากกับคอลัมน์นั้น มันไม่เคยเปลี่ยนแปลงและไม่เคยแสดงต่อผู้ใช้
spaghettidba

ทำไมพวกเขาต้องการ rowguidcol แยกต่างหาก โดยทั่วไปแล้วพวกเขาจะเลือกโครงการแบบใดถ้าพวกเขาสามารถทำได้สำหรับ PK และทำไม
JustinC

@spaghettidba พูดถึงการข้ามโดเมนคุณบอกพวกเขาบ่อยแค่ไหนว่ารูปแบบการออกแบบที่พวกเขาควรหรือไม่ควรใช้ในรหัสแอพของพวกเขาคืออะไร? บางทีพวกเขาควรจะยึดติดกับ "โดเมน" ของพวกเขา? ;-) นอกจากนี้การเพิ่มคอลัมน์ 16 ไบต์ลงในตารางทั้งหมดจะน่ากลัวสำหรับประสิทธิภาพและไม่ให้ประโยชน์
โซโลมอน Rutzky

คำตอบ:


7

โดยพื้นฐานแล้วพวกเขาบอกว่าแอปพลิเคชันไม่ควรนำสิ่งที่ใช้ในการจำลองแบบโดเมนมาใช้เท่านั้น (เป็นเพียง "สิ่ง DBA" สำหรับพวกเขา)

ฉันเห็นด้วยอย่างสมบูรณ์ แต่ ... คีย์หลักไม่ได้ใช้สำหรับการจำลองเท่านั้น (สมมุติว่าแอปพลิเคชันใช้ในบางวิธี) อาร์กิวเมนต์ไม่สมเหตุสมผลในบริบทนี้

ในกรณีใด ๆ เท่าที่ฉันทราบมีเพียง 2 วิธีสำหรับ "สิ่ง DBA" นี้เพื่อข้ามขอบเขตโดเมน:

  1. หากแอปพลิเคชันใช้คิวรีที่อ้างอิงROWGUIDCOLคอลัมน์เช่นนี้:

    DECLARE @a table (id uniqueidentifier ROWGUIDCOL);
    
    SELECT ROWGUIDCOL FROM @a;

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

  2. คอลัมน์คีย์หลักจะไม่สามารถอัปเดตได้อีกต่อไป หากแอปพลิเคชันทำสิ่งนี้และการเปลี่ยนแปลงจะไม่ถูกสร้างขึ้นเพื่อใช้อัลกอริทึมอื่นไม่มีทางเลือกนอกจากเพิ่มคอลัมน์ใหม่ในตารางดังนั้นจึงไม่จำเป็นต้องมีการสนทนา

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


ขอบคุณสำหรับคำตอบ. ไม่แอปพลิเคชันไม่ได้ทำ 1. หรือ 2 เพื่อความสมบูรณ์ตารางบางตารางได้ถูกตกแต่งด้วยคุณสมบัติ ROWGUIDCOL ใน PK แล้ว
spaghettidba

ในขณะที่ฉันยอมรับว่าการจำลองแบบควรโปร่งใสกับแอปพลิเคชัน แต่ฉันเชื่อว่าฐานข้อมูลที่ต้องเผยแพร่ต้องคำนึงถึงการจำลองแบบตั้งแต่แรก การจัดการข้อมูลผู้ใช้ในการจำลองแบบผสานนั้นเป็นแบบ PITA โดยสิ้นเชิงตัวอย่างเช่นถ้าคุณรู้ตั้งแต่เริ่มแรกคุณจะต้องรวมการเผยแพร่มันเป็นสิ่งหนึ่งที่จะหลีกเลี่ยง
spaghettidba

@spaghettidba: ใช่ฉันเห็นด้วยอย่างสมบูรณ์ว่าหากการจำลองแบบอยู่ในการ์ดฐานข้อมูลจะต้องได้รับการออกแบบมาอย่างแน่นอน บ่อยครั้งเพียงปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดจะได้รับประโยชน์สูงสุดจากที่นั่น มันเป็นฐานข้อมูลดั้งเดิมที่มีขนดกน่าเกลียดที่มักจะมีปัญหาในการออกแบบมากที่สุด จากประสบการณ์ของฉันการผสานการจำลองแบบโดยเฉพาะอย่างยิ่งมีความท้าทายมากกว่ากลไกการจำลองแบบอื่น ๆ
Jon Seigel

@spaghettidba และจอน: เพียง FYI การใช้ROWGUIDCOLในบริบทที่ (คือไม่ได้อยู่ในCREATE TABLE/ ALTER TABLEคำสั่ง) ได้รับการคัดค้านอย่างน้อยตั้งแต่SQL Server 2008 R2 (ค้นหา FeatureId 182) $ROWGUIDในความโปรดปรานของ
โซโลมอน Rutzky

6

ฉันเห็นด้วย. ตราบใดที่ไม่มีความจำเป็นที่ค่า PK จะสามารถเปลี่ยนแปลงได้ก็จะเป็นการดีกว่าถ้าจะใช้คอลัมน์ Uniqueidentifier ที่มีอยู่แล้วเป็น rowguidcol


5

"โดยทั่วไปแล้วพวกเขาบอกว่าแอปพลิเคชันไม่ควรนำสิ่งที่ใช้ในการจำลองแบบมาใช้ในโดเมนเท่านั้น (เป็นเพียง" สิ่ง DBA "สำหรับพวกเขา)

แต่ไม่ได้ใช้สำหรับการจำลองเท่านั้น นอกจากนี้ยังเป็น PK ของคุณด้วย (แล้ว)

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