พาร์ติชันคีย์ต้องเป็นส่วนหนึ่งของคีย์หลักด้วยหรือไม่

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

คอลัมน์พาร์ติชันจะต้องเป็นส่วนหนึ่งของหลักหรือไม่ มันแนะนำวิธีหนึ่งหรืออื่น ๆ ?
ฉันต้องสร้างดัชนีสำหรับพาร์ติชันคีย์หรือไม่ DBMS ทำมันเองโดยอัตโนมัติหรือไม่?

— AngryHacker
แหล่งที่มา

คำตอบ:

ไม่ใช่เลย.

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

ตัวอย่างเช่นถ้าคุณมีตารางOrdersที่มีเขตข้อมูลที่คุณจะมีโอกาสมากที่สุดพาร์ติชันบนพื้นฐานของเดือนและปีของ OrderDateOrderDate

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

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

แก้ไข

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

— JNK
แหล่งที่มา

ฉันรู้ว่ามันเก่า แต่มันทำให้ฉันผิดเส้นทางดังนั้นฉันคิดว่าฉันจะแสดงความคิดเห็นให้ผู้อื่น คอลัมน์พาร์ติชันจะต้องอยู่ในคีย์หลักหากคุณต้องการใช้ความสามารถของสวิทช์ของคุณสมบัติพาร์ติชัน หากไม่ได้อยู่ในคีย์หลักคุณจะได้รับข้อผิดพลาดนี้: Partition columns for a unique index must be a subset of the index key.

— Vaccano

ฉันเห็นด้วยกับ @Vaccano

— san

นอกเหนือจากคำตอบของ JNK คุณควรอ่านบทความนี้ซึ่งกล่าวถึงการจัดตำแหน่งพาร์ทิชันตารางและพาร์ทิชันดัชนี

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

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

แต่มันไม่ใช่ข้อกำหนด

— เคดรูส์
แหล่งที่มา

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

— srini.venigalla

@ srini.venigalla นั่นเป็นกรณีที่พบบ่อย แต่มีอีกกรณีที่พบบ่อย (เท่าเทียมกันใช่มั้ย) คือการแบ่งพาร์ติชันในบางสิ่งที่ไม่ได้เป็นส่วนหนึ่งของคีย์หลักหรือตัวเลือกผู้สมัครเลย - เนื่องจากการแบ่งพาร์ติชันมักใช้ในการเก็บถาวร ทางเลือกพาร์ทิชันที่ดี แต่ไม่มีอะไรที่แสดงว่าอาจเป็นส่วนหนึ่งของคีย์ การแบ่งพาร์ติชันเป็นคุณสมบัติระดับต่ำซึ่งค่อนข้างทั่วไปและมีรูปแบบการใช้งานที่แตกต่างและขัดแย้งกันอย่างน้อยสองรูปแบบซึ่งทั้งคู่มีแนวทางปฏิบัติที่ดีที่สุดที่ถูกต้องตามกฎหมาย

— เคดรูส์

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

ดังนั้นคำตอบคือใช่เป็นที่ต้องการเป็นส่วนหนึ่งของ PK หากไม่ใช่คีย์อื่นซึ่งดีพอที่จะเป็น PK

— srini.venigalla
แหล่งที่มา

ไม่เคยได้ยินกุญแจของผู้สมัคร หนึ่งจะระบุไว้ในคำสั่งตารางสร้าง / แก้ไขได้อย่างไร

— AngryHacker

คีย์ผู้สมัครเป็นอีกหนึ่งคีย์ที่ผ่านการรับรองว่าเป็นคีย์หลัก ตัวอย่างเช่น ID เป็นคีย์หลัก แต่ในตารางเดียวกันถ้าคอลัมน์อื่นเช่น PERSON_ID ยังสามารถระบุแถวที่ไม่ซ้ำกันซึ่งเรียกว่าคีย์ผู้สมัคร กฎการนอร์มัลไลซ์ที่ 2 และ 3 ควรยึดติดกับปุ่มตัวเลือกทั้งหมด

— srini.venigalla

เข้าใจ ส่วนที่ 2 ของคำถามของฉันคืออะไร

— AngryHacker

เช่นเดียวกับดัชนีอื่น ๆ ตัวอย่าง: สร้างดัชนี IX_ProductVendor_VendorID จากการจัดซื้อ ProductVendor (BusinessEntityID);

— srini.venigalla

สิ่งนี้ไม่ถูกต้องอย่างแน่นอน คุณสามารถแบ่งพาร์ติชันในหลายสาขาที่ไม่ได้เกี่ยวข้องกับการ PK OrderDateที่ทั้งหมดเช่น คุณมีข้อมูลสำรองการอ้างสิทธิ์ของคุณหรือไม่?

— JNK