สตริงเป็นคีย์หลักในฐานข้อมูล SQL

ฉันไม่คุ้นเคยกับฐานข้อมูลและทฤษฎีเบื้องหลังการทำงานของพวกเขา มันช้าลงหรือไม่จากจุดยืนประสิทธิภาพ (การแทรก / อัพเดต / การสืบค้น) เพื่อใช้ Strings สำหรับคีย์หลักมากกว่าจำนวนเต็ม?

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

ปัญหาอีกประการหนึ่งของการใช้ Strings เป็นคีย์หลักคือเนื่องจากดัชนีนั้นถูกจัดเรียงตามลำดับอย่างต่อเนื่องเมื่อมีการสร้างคีย์ใหม่ซึ่งจะอยู่ตรงกลางของลำดับที่ดัชนีต้องถูก resequenced ... หากคุณใช้ auto จำนวนเต็มจำนวนคีย์ใหม่จะถูกเพิ่มไปยังจุดสิ้นสุดของดัชนี

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

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

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

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

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

มีตัวแปรมากเกินไป ขึ้นอยู่กับขนาดของตารางดัชนีลักษณะของโดเมนคีย์สตริง ...

โดยทั่วไปจำนวนเต็มจะเร็วขึ้น แต่ความแตกต่างจะใหญ่พอที่จะสนใจหรือไม่ มันยากที่จะพูด.

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

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

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

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

โปรแกรมเมอร์และผู้ใช้แบบโต้ตอบที่ระบุคิวรีสามารถใช้คีย์ธรรมชาติเพื่อรับสิ่งที่ต้องการได้หรือไม่?

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

ดัชนีบ่งบอกถึงการเปรียบเทียบจำนวนมาก

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

แม้ว่าบางครั้งมันจะเร็วกว่าที่จะใช้สตริงเป็นคีย์หลักกว่าเพื่อเข้าร่วมเป็นพิเศษกับstring to numerical idตาราง

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

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

เหตุผลสองประการในการใช้จำนวนเต็มสำหรับคอลัมน์ PK:

1. เราสามารถกำหนดตัวตนสำหรับฟิลด์จำนวนเต็มซึ่งเพิ่มขึ้นโดยอัตโนมัติ

2. เมื่อเราสร้าง PKs db จะสร้างดัชนี (Cluster หรือ Non Cluster) ซึ่งเรียงลำดับข้อมูลก่อนที่จะถูกเก็บไว้ในตาราง โดยการใช้ข้อมูลประจำตัวบน PK เครื่องมือเพิ่มประสิทธิภาพไม่จำเป็นต้องตรวจสอบลำดับการจัดเรียงก่อนบันทึกเรกคอร์ด สิ่งนี้ช่วยปรับปรุงประสิทธิภาพการทำงานในตารางขนาดใหญ่

คุณมีเหตุผลอะไรที่มีสตริงเป็นคีย์หลัก

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

ด้วยวิธีนี้หากคุณค้นหาบนโต๊ะพวกเขาควรจะค่อนข้างเร็วและการเข้าร่วมและการค้นหาปกติทั้งหมดของคุณจะไม่ได้รับผลกระทบจากความเร็ว

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

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

จากมุมมองข้อกำหนด - แม้ว่านี่จะไม่ใช่ส่วนหนึ่งของคำถามของคุณ แต่ฉันต้องการพูดถึง เมื่อเราจัดการข้อมูลขนาดใหญ่ในตารางต่างๆเรามักจะมองหาชุดของคีย์ที่น่าจะเป็นซึ่งสามารถตั้งค่าสำหรับตารางเฉพาะ นี่เป็นหลักเนื่องจากมีหลายตารางและส่วนใหญ่แต่ละหรือบางตารางจะเกี่ยวข้องกับอื่น ๆ ผ่านความสัมพันธ์บางอย่าง (แนวคิดของ Foreign Key) ดังนั้นเราจึงไม่สามารถเลือกจำนวนเต็มเป็นคีย์หลักได้เสมอ แต่เราจะรวมกันของแอตทริบิวต์ 3, 4 หรือ 5 เป็นคีย์หลักสำหรับตารางนั้น และกุญแจเหล่านั้นสามารถใช้เป็นกุญแจต่างประเทศเมื่อเราต้องการเชื่อมโยงบันทึกกับตารางอื่น สิ่งนี้ทำให้มีประโยชน์ในการเชื่อมโยงเร็กคอร์ดในตารางต่าง ๆ เมื่อจำเป็น

ดังนั้นสำหรับการใช้งานที่เหมาะสม - เรามักจะรวมจำนวนเต็ม 1 หรือ 2 กับแอตทริบิวต์สตริง 1 หรือ 2 แต่อีกครั้งถ้าจำเป็นเท่านั้น

อาจมีความเข้าใจผิดที่เกี่ยวข้องกับสตริงในฐานข้อมูลใหญ่มาก เกือบทุกคนคิดว่าการแสดงตัวเลขของฐานข้อมูลนั้นมีขนาดเล็กกว่าสำหรับสตริง พวกเขาคิดว่าในตัวเลข db-s แสดงในหน่วยความจำ แต่มันไม่เป็นความจริง ในกรณีส่วนใหญ่การแทนค่าตัวเลขจะใกล้เคียงกับสตริงมากกว่าเช่นการแทนค่าอื่น ๆ

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

โดยค่าเริ่มต้น ASPNetUserIds เป็น 128 อักขระถ่านและประสิทธิภาพก็ดี

ถ้าคีย์HASจะไม่ซ้ำกันในตารางมันควรจะเป็นกุญแจสำคัญในการ นี่คือเหตุผล;

primary string key = แก้ไขความสัมพันธ์ของฐานข้อมูล, 1 สตริงคีย์ (หลัก), และ 1 สตริงดัชนี (The Primary)

ตัวเลือกอื่นเป็น int int ปกติ แต่ถ้าสตริงHASเป็นค่าเฉพาะคุณอาจยังคงต้องเพิ่มดัชนีเนื่องจากแบบสอบถามแบบไม่หยุดเพื่อตรวจสอบหรือตรวจสอบว่าเป็นค่าที่ไม่ซ้ำกัน

ดังนั้นการใช้รหัสประจำตัว int = ความสัมพันธ์ของฐานข้อมูลที่ไม่ถูกต้อง, 1 int คีย์ (หลัก), 1 int ดัชนี (หลัก), น่าจะเป็นดัชนีสตริงที่ไม่ซ้ำกันและด้วยตนเองต้องตรวจสอบสตริงเดียวกันไม่มีอยู่ (เช่นเช็ค sql )

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