ข้อดีและข้อเสียของคีย์ฐานข้อมูล GUID / UUID

ฉันเคยทำงานกับระบบฐานข้อมูลจำนวนมากในอดีตที่การย้ายรายการระหว่างฐานข้อมูลจะทำได้ง่ายขึ้นมากหากคีย์ฐานข้อมูลทั้งหมดเป็นค่าGUID / UUID ฉันได้พิจารณาที่จะลงเส้นทางนี้สองสามครั้ง แต่มีความไม่แน่นอนอยู่เสมอโดยเฉพาะอย่างยิ่งเกี่ยวกับประสิทธิภาพและ URL ที่ไม่สามารถอ่านได้

มีใครทำงานอย่างกว้างขวางกับ GUIDs ในฐานข้อมูลหรือไม่ ฉันจะได้ประโยชน์อะไรจากการทำเช่นนั้นและสิ่งที่เป็นไปได้ที่จะเกิดข้อผิดพลาด?

ข้อดี:

• สามารถสร้างพวกเขาออฟไลน์
• ทำให้การจำลองแบบเล็กน้อย (ตรงข้ามกับ int ซึ่งทำให้ยากจริงๆ)
• ORM มักจะชอบพวกเขา
• แอพพลิเคชั่นที่ไม่เหมือนใคร ดังนั้นเราสามารถใช้ PK จาก CMS ของเรา (guid) ในแอปของเรา (เช่น guid) และรู้ว่าเราไม่เคยได้รับการปะทะกัน

ข้อเสีย:

• การใช้พื้นที่มากขึ้น แต่พื้นที่ราคาถูก (เอ้อ)
• ไม่สามารถสั่งซื้อด้วย ID เพื่อรับใบสั่งแทรก
• สามารถดูน่าเกลียดใน URL แต่จริงๆแล้ว WTF คุณกำลังใส่คีย์ REAL DB ใน URL! (จุดนี้โต้แย้งในความคิดเห็นด้านล่าง)
• ยากที่จะทำการดีบักด้วยตนเอง แต่ไม่ยาก

โดยส่วนตัวแล้วฉันใช้มันสำหรับ PK ส่วนใหญ่ในระบบที่มีขนาดพอเหมาะ แต่ฉันได้รับ "การฝึกอบรม" ในระบบที่ทำซ้ำทั่วทุกสถานที่ดังนั้นเราจึงมีมัน YMMV

ฉันคิดว่าข้อมูลที่ซ้ำกันนั้นเป็นขยะ - คุณสามารถรับข้อมูลซ้ำได้ แต่คุณทำได้ ปุ่มตัวแทนมักจะขมวดคิ้วตามที่ฉันเคยทำงาน เราใช้ระบบคล้าย WordPress แต่:

• ID เฉพาะสำหรับแถว (GUID / อะไรก็ตาม) ไม่ปรากฏแก่ผู้ใช้
• รหัสสาธารณะถูกสร้างขึ้นครั้งเดียวจากบางฟิลด์ (เช่นชื่อ - ทำให้เป็นชื่อเรื่องของบทความ)

อัปเดต: ดังนั้นสิ่งนี้ได้รับ +1 มากและฉันคิดว่าฉันควรชี้ให้เห็นข้อเสียใหญ่ของ GUID PK's: ดัชนีแบบกลุ่ม

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

ดังนั้นหากคุณต้องการเพิ่มประสิทธิภาพการทำงานอาจใช้ auto-inc INT และสร้าง GUID ถ้าคุณต้องการแบ่งปันกับคนอื่น (เช่นแสดงให้ผู้ใช้เห็นใน URL)

@ Matt Sheppard:

สมมติว่าคุณมีโต๊ะลูกค้า แน่นอนว่าคุณไม่ต้องการให้ลูกค้าอยู่ในตารางมากกว่าหนึ่งครั้งมิฉะนั้นความสับสนจะเกิดขึ้นตลอดแผนกขายและโลจิสติกส์ของคุณ (โดยเฉพาะอย่างยิ่งถ้าหลายแถวเกี่ยวกับลูกค้ามีข้อมูลแตกต่างกัน)

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

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

"สถาปนิก" บางคนอาจบอกคุณว่า "โอ้ แต่เราจัดการกับข้อ จำกัด ของลูกค้าจริงในระดับแอปของเรา!" ขวา. แฟชั่นเกี่ยวกับภาษาการเขียนโปรแกรมสำหรับวัตถุประสงค์ทั่วไปและ (โดยเฉพาะ) กรอบชั้นกลางเปลี่ยนแปลงตลอดเวลาและโดยทั่วไปจะไม่มีวันหมดอายุฐานข้อมูลของคุณ และมีโอกาสดีมากที่คุณจะต้องเข้าถึงฐานข้อมูลโดยไม่ต้องผ่านแอปพลิเคชันปัจจุบัน == ปัญหา (แต่โชคดีที่คุณและ "สถาปนิก" หายไปนานดังนั้นคุณจะไม่ต้องไปทำความสะอาดให้วุ่นวาย) กล่าวอีกนัยหนึ่ง: รักษาข้อ จำกัด ที่ชัดเจนในฐานข้อมูล (และในระดับอื่น ๆ เช่นกันถ้าคุณมี เวลา).

กล่าวอีกนัยหนึ่ง: อาจมีเหตุผลที่ดีในการเพิ่มคอลัมน์ GUID ลงในตาราง แต่โปรดอย่าหลงลืมสิ่งนี้เพื่อลดความทะเยอทะยานของคุณลงเพื่อความสอดคล้องภายในข้อมูลจริง (== ที่ไม่ใช่ GUID)

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

GUID อาจทำให้คุณมีปัญหามากในอนาคตหากใช้เป็น "ตัวถอดรหัส" การปล่อยให้ข้อมูลที่ซ้ำซ้อนเข้าสู่ตารางของคุณ หากคุณต้องการใช้ GUID โปรดพิจารณายังคงรักษาข้อ จำกัด UNIQUE ไว้ในคอลัมน์อื่น ๆ

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

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

มีปัญหาประสิทธิภาพบางอย่างเช่นการแตกแฟรกเมนต์ดัชนี แต่สิ่งเหล่านี้สามารถแก้ไขได้อย่างง่ายดาย (หวี guys โดย jimmy nillson: http://www.informit.com/articles/article.aspx?p=25862 )

แก้ไขรวมสองคำตอบของคำถามนี้

@ Matt Sheppard ฉันคิดว่าเขาหมายความว่าคุณสามารถทำสำเนาแถวด้วย GUID ที่แตกต่างกันเป็นคีย์หลักได้ นี่เป็นปัญหาของรหัสตัวแทนประเภทใด ๆ ไม่ใช่แค่ GUID และเช่นเดียวกับที่เขาบอกว่ามันง่ายต่อการแก้ไขโดยการเพิ่มข้อ จำกัด ที่ไม่เหมือนใครให้กับคอลัมน์ที่ไม่ใช่กุญแจ ทางเลือกคือการใช้คีย์ธรรมชาติและผู้ที่มีปัญหาจริง ..

อีกหนึ่งปัญหาเล็ก ๆ ที่ต้องพิจารณาด้วยการใช้ GUIDS เป็นคีย์หลักหากคุณใช้คอลัมน์นั้นเป็นดัชนีคลัสเตอร์ (เป็นวิธีปฏิบัติทั่วไป) คุณกำลังจะใช้งานการแทรกเนื่องจากลักษณะของ guid ที่ไม่ได้เริ่มเรียงตามลำดับอยู่แล้วดังนั้นจะเป็นการแยกหน้า ฯลฯ เมื่อคุณแทรก บางสิ่งที่ต้องพิจารณาหากระบบกำลังมี IO สูง ...

คีย์หลัก-รหัสเมื่อเทียบกับ guids

ต้นทุนของ GUID เป็นคีย์หลัก (SQL Server 2000)

Myths, GUID vs. Autoincrement (MySQL 5)

นี่คือสิ่งที่คุณต้องการจริงๆ

ข้อดีของ UID

• ไม่ซ้ำกันในทุกตารางทุกฐานข้อมูลทุกเซิร์ฟเวอร์
• ช่วยให้การรวมระเบียนจากฐานข้อมูลต่างๆง่ายขึ้น
• ช่วยให้กระจายฐานข้อมูลข้ามเซิร์ฟเวอร์ได้ง่าย
• คุณสามารถสร้าง ID ได้ทุกที่แทนที่จะต้องไปที่ฐานข้อมูล
• สถานการณ์จำลองแบบส่วนใหญ่ต้องการคอลัมน์ GUID อยู่แล้ว

ข้อด้อยของ GUID

• มันใหญ่กว่าค่าดัชนี 4 ไบต์แบบเดิมถึง 4 เท่า สิ่งนี้อาจมีประสิทธิภาพที่ร้ายแรงและความหมายของพื้นที่จัดเก็บหากคุณไม่ระวัง
• ยุ่งยากในการแก้ปัญหา (โดยที่ userid = '{BAE7DF4-DDF-3RG-5TY3E3RF456AS10}')
• GUID ที่สร้างขึ้นควรเรียงตามลำดับบางส่วนเพื่อประสิทธิภาพที่ดีที่สุด (เช่น newsequentialid () บน SQL 2005) และเพื่อให้สามารถใช้ดัชนีแบบคลัสเตอร์ได้

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

RDBMs มักจะให้ความมั่นใจในความไม่เหมือนใครของคีย์หลักและตรวจสอบให้แน่ใจว่าการค้นหาโดยคีย์ในโครงสร้างที่เรียกว่า BTree ซึ่งเป็นโครงสร้างการค้นหาที่มีปัจจัยการแยกย่อยขนาดใหญ่ ตอนนี้ ID จำนวนเต็มต่อเนื่องจะทำให้ส่วนแทรกเกิดขึ้นเพียงอันเดียวด้านของต้นไม้ทำให้ส่วนใหญ่ของโหนดใบไม่ถูกแตะต้อง การเพิ่ม UUID แบบสุ่มจะทำให้การแทรกเพื่อแยกปมใบไม้โหนดทั่วดัชนี

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