คีย์หลักของอักขระเทียบกับจำนวนเต็ม


30

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

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

ฉันใช้ MySQL ถ้าเรื่องนั้น

[แก้ไข]
ตารางค้นหาเหล่านี้มีการเพิ่มระเบียนใหม่นาน ๆ ครั้ง พวกเขาจะดูแลด้วยตนเองและคีย์ตามตัวอักษรจะถูกสร้างขึ้นด้วยตนเองเช่นกัน นี่คือตัวอย่าง:

      CUISINES
 ID      Description
-----  --------------
CHNSE  Chinese
ITALN  Italian
MXICN  Mexican

คำตอบ:


22

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

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

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

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

หรือหากคุณเพียงแค่ติดตามประเทศต้นทางและไม่ใช่เฉพาะภูมิภาคของอาหาร (กวางตุ้งเสฉวนซิซิลีอุมเบียนคาลาเบียนยูกาเตคานโออาซาแคน ฯลฯ ) คุณสามารถใช้รหัส ISO 3166ได้เสมอ

หากฉันมี 10,000 สูตรไม่ได้ความแตกต่างระหว่างคีย์ 5 ตัวอักษรและ 20 ตัวอักษรเริ่มเพิ่มขึ้นหรือไม่

พื้นที่มีราคาถูก เมื่อคุณพูดถึง 10,000,000 สูตรที่คุณกำลังทำในการดำเนินการ OLAP ด้วยสูตร 10k คุณกำลังดูพื้นที่ 150k

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

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


@ BrianBallsun-Stanton หากคุณมีข้อมูลเรียงลำดับขนาดใหญ่ที่เกี่ยวข้องกับตารางการค้นหาเหล่านี้พื้นที่เก็บข้อมูลไม่ถูก (ในแง่ของความเร็วในการค้นหา) เนื่องจากความเร็วในการอ่านดิสก์เป็นคอขวดใน RDB ใด ๆ ที่ไม่สามารถแคชทั้งหมดใน RAM ฉันพบสิ่งนี้ในขณะที่พยายามพัฒนา RDB schema ที่สามารถแข่งขันกับธุรกิจ DB อนุกรมเวลาที่ดีที่สุดได้อย่างเปิดเผยฉันไม่มีความสัมพันธ์กับ Skyspark ยกเว้นว่าพวกเขาเรียกเก็บเงินจำนวนมากจากนายจ้างของฉันเพื่อใช้ DB ที่มีประสิทธิภาพมาก
เตาแก๊ส

8

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


3

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

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

หากคุณมีข้อมูลต่อเนื่องจำนวนมาก (ไฟล์บันทึก, อนุกรมเวลา, การวิเคราะห์, ข้อความหรือคำพูด) ที่มีลิงค์ (ความสัมพันธ์) ไปยังตารางการค้นหาใด ๆ ของคุณคุณจะพบว่าพื้นที่เก็บข้อมูลมีความสำคัญต่อความเร็วในการสืบค้น การวิเคราะห์ที่ถูกต้อง Ballsun-สแตนตันของวิธีการที่ราคาถูกมีพื้นที่ใน $ เนื่องจากเวลาการสืบค้นส่วนใหญ่ (สำหรับข้อมูลตามลำดับ) ถูกใช้เพื่ออ่านดิสก์พื้นที่ไม่ถูกในแง่ของเวลา (เป็นเปอร์เซ็นต์ของเวลาแบบสอบถามโดยรวม) ดังนั้นหาก RDB ของคุณโดยอัตโนมัติและมีประสิทธิภาพในการบีบอัด / คลายคีย์ต่างประเทศทั้งหมด (คีย์ไปยังระเบียนที่เกี่ยวข้อง) คุณจะต้องการให้คีย์ทั้งหมดของคุณIntซึ่งมีประสิทธิภาพมากที่สุดในแง่ของพื้นที่ดิสก์ (และความเร็วในการอ่าน) ต่อหน่วยของข้อมูล เนื้อหา (เอนโทรปี) FYI MyISAM ในMySql มีข้อ จำกัดในสิ่งที่คุณสามารถทำได้กับแถวข้อมูลที่ถูกบีบอัด (อ่านอย่างเดียว) กล่าวอีกนัยหนึ่งจำนวนเต็มที่เพิ่มขึ้นโดยอัตโนมัติจะถูกบีบอัดให้มากที่สุดเท่าที่จะเป็นไปได้ในทางทฤษฎีเนื่องจากข้อ จำกัด ขนาดต่ำสุดขั้นต่ำในฟิลด์จำนวนเต็ม DB ส่วนใหญ่ และการบีบอัดนั้นมาโดย:

  1. การบีบอัดเวลา / การลงโทษการบีบอัดแบบสอบถาม
  2. บทลงโทษการอ่านดิสก์เวลาค้นหา
  3. ข้อ จำกัด ฐานข้อมูลแบบอ่านอย่างเดียวหรืออื่น ๆ สำหรับบันทึกหรือคีย์ข้อมูลที่บีบอัด

มีเหตุผลว่าทำไม ORM ที่ได้รับความนิยมและมีประสิทธิภาพเช่นDjango เริ่มต้นเป็นจำนวนเต็มที่เพิ่มขึ้นโดยอัตโนมัติสำหรับ PKsและทำไมคำถาม SOอื่น ๆถึงได้ข้อสรุปเดียวกัน

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