ข้อเสียของการมีคอลัมน์จำนวนเต็มเดียวเป็นคีย์หลักเสมอ

ภายในเว็บแอปพลิเคชั่นตัวหนึ่งที่ฉันทำงานอยู่การดำเนินการฐานข้อมูลทั้งหมดจะถูกทำให้เป็นนามธรรมโดยใช้แหล่งเก็บข้อมูลทั่วไปที่กำหนดไว้ผ่าน Entity Framework ORM

อย่างไรก็ตามเพื่อให้มีการออกแบบที่เรียบง่ายสำหรับที่เก็บข้อมูลทั่วไปตารางที่เกี่ยวข้องทั้งหมดจะต้องกำหนดจำนวนเต็มเฉพาะ ( Int32ใน C #, intใน SQL) จนถึงขณะนี้ได้รับเสมอ PK IDENTITYของตารางและยังได้

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

โดยทั่วไปแล้วแอปพลิเคชันเลเยอร์จะดำเนินการดังต่อไปนี้:

• การโหลดข้อมูลเริ่มต้นจากตาราง (*) -SELECT * FROM table
• อัพเดท -UPDATE table SET Col1 = Val1 WHERE Id = IdVal
• ลบ -DELETE FROM table WHERE Id = IdVal
• ส่วนแทรก -INSERT INTO table (cols) VALUES (...)

การดำเนินการน้อยกว่าปกติ:

• แทรกจำนวนมาก - BULK INSERT ... into tableติดตาม (*) โดยโหลดข้อมูลทั้งหมด (เพื่อดึงข้อมูลตัวระบุที่สร้างขึ้น)
• การลบแบบกลุ่ม - เป็นการดำเนินการลบแบบปกติ แต่ "ใหญ่" จากมุมมองของ ORM:DELETE FROM table where OtherThanIdCol = SomeValue
• การอัปเดตจำนวนมาก - เป็นการดำเนินการอัปเดตตามปกติ แต่ "ใหญ่" จากมุมมองของ ORM:UPDATE table SET SomeCol = SomeVal WHERE OtherThanIdCol = OtherValue

* ตารางเล็ก ๆ ทั้งหมดถูกแคชในระดับแอปพลิเคชันและเกือบทั้งหมดSELECTsจะไม่สามารถเข้าถึงฐานข้อมูลได้ รูปแบบทั่วไปคือการโหลดครั้งแรกและจำนวนมากของINSERTs, UPDATEs และDELETEs

ขึ้นอยู่กับการใช้งานแอปพลิเคชันปัจจุบันมีโอกาสน้อยมากที่จะเข้าถึงระเบียน 100M ในตารางใด ๆ

คำถาม: จากมุมมองของ DBA มีปัญหาที่สำคัญที่ฉันสามารถพบเจอได้ด้วยการ จำกัด การออกแบบตารางนี้หรือไม่?

[แก้ไข]

หลังจากอ่านคำตอบ (ขอบคุณสำหรับข้อเสนอแนะที่ยอดเยี่ยม) และบทความอ้างอิงฉันรู้สึกว่าฉันต้องเพิ่มรายละเอียดเพิ่มเติม:

1. เฉพาะแอปพลิเคชันปัจจุบัน - ฉันไม่ได้พูดถึงเกี่ยวกับแอปพลิเคชันเว็บปัจจุบันเนื่องจากฉันต้องการเข้าใจว่าสามารถนำโมเดลนี้ไปใช้กับแอปพลิเคชันอื่นได้หรือไม่ อย่างไรก็ตามกรณีเฉพาะของฉันคือแอปพลิเคชันที่ดึงข้อมูลเมตาจำนวนมากจาก DWH ข้อมูลต้นฉบับค่อนข้างยุ่งเหยิง (denormalized ในทางที่แปลกมีความไม่สอดคล้องกันไม่มีตัวระบุตามธรรมชาติในหลาย ๆ กรณี ฯลฯ ) และแอปของฉันกำลังสร้างเอนทิตีแยกชัดเจน นอกจากนี้ตัวบ่งชี้ที่สร้างขึ้นจำนวนมากIDENTITYจะปรากฏขึ้นเพื่อให้ผู้ใช้สามารถใช้เป็นรหัสธุรกิจได้ นี้นอกจากรหัส refactoring ใหญ่ไม่รวมการใช้งานของ guid ของ

2. "พวกเขาไม่ควรเป็นวิธีเดียวที่จะระบุแถวที่ไม่ซ้ำกัน" (Aaron Bertrand ♦) - นั่นคือคำแนะนำที่ดีมาก ตารางทั้งหมดของฉันยังกำหนด UNIQUE CONSTRAINT เพื่อให้แน่ใจว่าไม่อนุญาตให้ทำซ้ำธุรกิจ

3. การออกแบบที่ขับเคลื่อนด้วยแอพ Front-end และการออกแบบที่ขับเคลื่อนด้วยฐานข้อมูล - ตัวเลือกการออกแบบเกิดจากปัจจัยเหล่านี้

   1. ข้อ จำกัด Entity Framework - อนุญาตให้มีหลาย PKs ได้ แต่ไม่สามารถอัพเดตค่าได้

   2. ข้อ จำกัด ที่กำหนดเอง - การมีคีย์จำนวนเต็มเดี่ยวช่วยลดความซับซ้อนของโครงสร้างข้อมูลและรหัสที่ไม่ใช่ SQL เช่นรายการทั้งหมดมีคีย์จำนวนเต็มและค่าที่แสดง ที่สำคัญกว่านั้นคือรับประกันได้ว่าตารางใด ๆ ที่ทำเครื่องหมายไว้สำหรับแคชจะสามารถใส่ลงในUnique int key -> valueแผนที่ได้

4. แบบสอบถามแบบใช้เลือกข้อมูลที่ซับซ้อน - สิ่งนี้แทบจะไม่เกิดขึ้นเพราะข้อมูลตารางเล็ก ๆ (<20-30K ระเบียน) ถูกแคชในระดับแอปพลิเคชัน สิ่งนี้จะทำให้ชีวิตของคุณหนักขึ้นเล็กน้อยเมื่อเขียนรหัสแอปพลิเคชัน (ยากที่จะเขียน LINQ) แต่ฐานข้อมูลนั้นยอดเยี่ยมกว่า:

   1. มุมมองรายการ - จะไม่สร้างSELECTข้อความค้นหาในการโหลด (ทุกอย่างถูกแคช) หรือแบบสอบถามที่มีลักษณะดังนี้:

      SELECT allcolumns FROM BigTable WHERE filter1 IN (val1, val2) AND filter2 IN (val11, val12)

      ค่าที่ต้องการอื่น ๆ ทั้งหมดจะถูกดึงผ่านการค้นหาแคช (O (1)) ดังนั้นจึงไม่มีการสร้างแบบสอบถามที่ซับซ้อน

   2. แก้ไขมุมมอง - จะสร้างSELECTคำสั่งเช่นนี้:

      SELECT allcolumns FROM BigTable WHERE PKId = value1

(ตัวกรองและค่าทั้งหมดคือints)

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

ฉันต่อต้านการเพิ่มไปยังตารางทุกตารางในบล็อกโพสต์จาก 2010:

• นิสัยไม่ดีที่จะเตะ: วางคอลัมน์ประจำตัวในทุกตาราง

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

จากประสบการณ์ของฉันเหตุผลหลักที่ทำให้ฉันใช้ ID แยกต่างหากสำหรับทุกตารางมีดังต่อไปนี้:

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

จากมุมมองของ DBA สิ่งที่ทำให้ DB ช้าหรือป่องนั้นไม่ใช่ 4 ไบต์ (หรืออะไรก็ตาม) ต่อแถว แต่สิ่งต่าง ๆ เช่นดัชนีที่ผิดหรือขาดหายไปการปรับโครงสร้างตาราง / ดัชนีที่ถูกลืมพารามิเตอร์การปรับ RAM / tablespace ผิด ละเลยที่จะใช้ตัวแปรผูกและอื่น ๆ สิ่งเหล่านี้สามารถทำให้ DB ช้าลงตามปัจจัยของ 10, 100, 10000 ... ไม่ใช่คอลัมน์ ID เพิ่มเติม

ดังนั้นแม้ว่าจะมีข้อเสียทางเทคนิคที่สามารถวัดได้ของการเพิ่มอีก 32 บิตต่อแถวมันไม่ใช่คำถามว่าคุณสามารถเพิ่มประสิทธิภาพ ID ออกไปได้หรือไม่ แต่ ID นั้นจะมีความสำคัญในบางจุดหรือไม่ มีแนวโน้มมากกว่าไม่ และฉันจะไม่นับผลประโยชน์ "อ่อน" ทั้งหมดจากท่าทางการพัฒนาซอฟต์แวร์ (เช่นตัวอย่าง ORM ของคุณหรือความจริงที่ว่ามันช่วยให้นักพัฒนาซอฟต์แวร์ง่ายขึ้นเมื่อ ID ทั้งหมดโดยการออกแบบมีประเภทข้อมูลเดียวกันเป็นต้น) .

หมายเหตุ: โปรดทราบว่าคุณไม่จำเป็นต้องมี ID แยกต่างหากสำหรับn:mตารางการเชื่อมโยงเพราะสำหรับตารางดังกล่าว ID ของหน่วยงานที่เกี่ยวข้องควรจัดทำคีย์หลัก ตัวอย่างที่ผ่านมาจะเป็นการn:mเชื่อมโยงที่แปลกซึ่งอนุญาตให้มีการเชื่อมโยงหลายรายการระหว่างสองเอนทิตี้เดียวกันด้วยเหตุผลที่แปลกประหลาดไม่ว่าจะด้วยเหตุผลใดก็ตามพวกมันจะต้องมีคอลัมน์ ID ของตัวเองในการสร้าง PK มีเป็นห้องสมุดออมที่ไม่สามารถจัดการกับปลากัดสวยงามหลายคอลัมน์ แต่เพื่อที่จะเป็นเหตุผลที่จะผ่อนปรนกับนักพัฒนาถ้าพวกเขาจะต้องทำงานร่วมกับห้องสมุดดังกล่าว

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

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

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

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

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

ฉันจะบอกว่าจำนวนเต็ม PK จะไม่กัดคุณจนกว่าคุณจะวางแผนที่จะรวมข้อมูลจากแหล่งที่แยกจากกันหรือคุณอาจมีข้อมูลที่เกินขนาด จำกัด จำนวนเต็ม - มันสนุกและเกมจนกว่าคุณจะหมดพื้นที่สำหรับแทรก .

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

วางกัน:

• สงครามศาสนา (google surrogate กับคีย์ธรรมชาติ)
• ปัญหาแยกต่างหากของดัชนีกลุ่มใดที่จะนิยามบนตารางของคุณ
• ความมีชีวิตของการแคชข้อมูลทั้งหมดของคุณ

หากคุณใช้การลบ / อัปเดตจำนวนมากตามความเหมาะสมและมีดัชนีเพื่อสนับสนุนการดำเนินการดังกล่าวฉันไม่คิดว่าคุณจะมีปัญหาเนื่องจากมาตรฐาน PK ที่คุณใช้
อาจเป็นไปได้ว่าถ้าคุณมี EF สร้างแบบสอบถามด้วยการรวม ฯลฯ พวกเขาจะไม่มีประสิทธิภาพเท่าที่ควรกับที่เก็บคีย์หลักตามธรรมชาติ แต่ฉันไม่รู้เกี่ยวกับพื้นที่นั้นเพื่อพูดอย่างแน่นอน

คุณมีปัจจัยสองสามอย่างที่จะช่วยแนะนำคุณ

1. นิยามและข้อมูลจำเพาะ

   หากมีการกำหนดบางสิ่งบางอย่างที่ไม่ซ้ำกันโดยงานหรือกฎหมายของฟิสิกส์ที่คุณกำลังเสียเวลาของคุณด้วยปุ่มตัวแทน

2. ความเป็นเอกลักษณ์

   เพื่อความเป็นส่วนตัวการเข้าร่วมและการทำงานของฐานข้อมูลระดับสูงคุณจะต้อง (a) คอลัมน์ที่ไม่ซ้ำ (b) คอลัมน์ที่ไม่ซ้ำกัน

   สกีมาปกติที่ได้รับการจัดมาตรฐานอย่างเพียงพอทั้งหมด (1NF) จะให้หนึ่งต่อไปนี้ หากพวกเขาไม่คุณควรสร้าง หากคุณมีบัญชีรายชื่อผู้คนที่ตั้งเป็นอาสาสมัครในวันอาทิตย์และมีชื่อและนามสกุลคุณจะต้องรู้เมื่อคุณมี Joe Bobs สองคน

3. การใช้งานและการเพิ่มประสิทธิภาพ

   int มีแนวโน้มที่จะเป็นรูปแบบข้อมูลขนาดเล็กที่รวดเร็วสำหรับการเปรียบเทียบและความเท่าเทียมกัน เปรียบเทียบกับสตริง Unicode ซึ่งการเรียงหน้าสามารถขึ้นอยู่กับโลแคล (ตำแหน่งที่ตั้งและภาษา) การจัดเก็บ 4242 ในสตริง ASCII / UTF8 คือ 4 ไบต์ จัดเก็บเป็นจำนวนเต็มพอดีใน 2 ไบต์

ดังนั้นเมื่อพูดถึงข้อเสียคุณมีปัจจัยบางอย่าง

1. ความสับสนและความกำกวม

   1. @Aaron Bertrand บล็อกรายการผลรวมนี้ดีขึ้น ไม่ใช่การจัดทำเอกสารด้วยตนเองเพื่อให้มีOrderIDตามข้อมูลจำเพาะและภารกิจจากนั้นกำหนด " OrderID " ผ่านการใช้ฐานข้อมูล บางครั้งคุณต้องอธิบายให้ชัดเจนว่าหรือสร้างการประชุม แต่นี่อาจเป็นการเพิ่มความสับสน

2. ช่องว่าง

   จำนวนเต็มยังคงเพิ่มพื้นที่ลงในแถว และถ้าคุณไม่ได้ใช้มันก็ไม่มีจุดประสงค์

3. การจัดกลุ่ม

   คุณสามารถสั่งซื้อข้อมูลได้ทางเดียวเท่านั้น หากคุณกำหนดคีย์ตัวแทนที่ไม่ต้องการคุณจัดกลุ่มด้วยวิธีนั้นหรือเป็นวิธีการของคีย์ธรรมชาติ