มีเหตุผลใดที่จะใช้ขนาด VARCHAR ปัดเศษเป็นออฟเซ็ต 128/256/4096 ไบต์?

14

ใน schema ของฐานข้อมูลฉันมักสังเกตว่าขนาด VARCHAR ถูกปัดเศษเป็น byte offsets 128/256 หรือ 4096 ฉันเคยทำมาก่อนเช่นกันและแนวคิดเบื้องหลังมันอาจเป็นสิ่งที่มีประสิทธิภาพ

อย่างไรก็ตามในปัจจุบันยังมีเหตุผลที่ถูกต้องหรือไม่? ฉันมักจะใช้ '50', '100' หรือ '200' เป็น VARCHAR ขนาดวันนี้เนื่องจากพวกเขาเป็นธรรมชาติมากขึ้นและมักจะแสดงในการตรวจสอบการตรวจสอบกับผู้ใช้

database database-design

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

2

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

— Jan Hudec

1

ไม่ว่าจะมีข้อได้เปรียบด้านประสิทธิภาพใด ๆ หรือไม่ขึ้นอยู่กับว่าจะใช้ฐานข้อมูลใด MySQL และ DB2 นั้นมีการใช้งานที่แตกต่างกันมาก

— David Thornley

11

เหตุผลเดียวที่ฉันคิดได้คือถ้า DBMS เก็บค่าของคอลัมน์เรียงตามลำดับและขนาดไม่ถูกปัดเป็นพลังของ 2 ดังนั้นองค์ประกอบบางอย่างอาจต้อง "แยก" ออกเป็นสองหน้าบนฮาร์ด ไดรฟ์ (เช่น 10 ไบต์แรกในหน้า n และ 40 ไบต์ถัดไปในหน้า n + 1) ซึ่งในบางกรณีอาจนำไปสู่การอ่านสองครั้งจากฮาร์ดไดรฟ์แทนหนึ่ง

มีโอกาสมากขึ้นที่ @Jan Hudec ชี้ว่าผู้เขียนโปรแกรมหลายคนคิดว่า "128" หรือ "256" เป็น "ตัวเลขรอบดี" ซึ่งทำให้พวกเขาเป็นตัวเลือกที่เป็นธรรมชาติมากกว่าตัวเลขแปลก ๆ เช่น 137, 19 หรือ 100

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

1

"โปรแกรมเมอร์หลายคนคิดว่า 128 หรือ 256 เป็นตัวเลขกลมดี" เราเป็นคนที่คลั่งไคล้แน่นอน :-)

— Konamiman

2

โปรดทราบว่าคุณต้องมีอย่างน้อยหนึ่งไบต์ในการจัดเก็บความยาวของข้อมูลดังนั้นหากคำอธิบายแรกของคุณเป็นจริงเราจะเห็นข้อ จำกัด จำนวน 31, 63, 127, 255 หรือ 510 ไบต์

— dan04

1

1 ไบต์เพื่อระบุความยาวจะอนุญาตให้ใช้สตริงที่มีความยาวสูงสุด 255 อักขระ (ไม่ใช่ 256) SQL Server และฉันเดาว่าระบบอื่นส่วนใหญ่ใช้สองไบต์

— Philip Kelley

4

โดยทั่วไปไม่มีเหตุผลสำหรับความยาวคอลัมน์เหล่านั้น จะไม่มีการปรับปรุงประสิทธิภาพของคอลัมน์ varchar (100) เมื่อเทียบกับคอลัมน์ varchar (128)

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

ตัวอย่างเช่นนี่เป็นตัวอย่างที่ดีของข้อ จำกัด ของระบบฐานข้อมูลสำหรับ SQL Server:

http://msdn.microsoft.com/en-us/library/ms186981.aspx

ความยาวรวมของแถวมีความสำคัญมากกว่าความยาวของคอลัมน์แต่ละคอลัมน์

— Jon Raynor
แหล่งที่มา

3

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

BTW ฉันได้ย้ายความกว้างของคอลัมน์ไปยังหมายเลขชุด b / c มันแปลกที่จะบอกผู้ใช้ข้อ จำกัด ถ่านคือ 256 ตัวอักษร

และฐานข้อมูลเก่ามากบางแห่ง จำกัด คุณไว้ที่ 256 char-width column

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

2

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

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

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

2

ในขณะที่ฉันไม่คุ้นเคยกับระบบ DBMS ทั้งหมดหน่วยเก็บข้อมูล "ทางกายภาพ" ที่เล็กที่สุดใน Oracle คือ "บล็อก" ซึ่งโดยค่าเริ่มต้นคือขนาด 2KB การฝึกการปรับขนาดคอลัมน์ของคุณด้วยพลังของทั้งสองนั้นเป็นส่วนหนึ่งของการปรับขนาดแถวของคุณให้ใหญ่ขึ้นเพื่อให้พอดีกับบล็อกการจัดเก็บ การกำหนดขนาดคอลัมน์ของคุณดังนั้นหนึ่งแถวจะต้องใช้หนึ่งไบต์มากกว่าขนาดบล็อกจะต้องมีการจัดสรรสองบล็อกและแถวของคุณก็จะขยายออกเป็นสองบล็อกทำให้การอ่านการแทรกและการสแกนใช้เวลานานกว่าถ้าคุณพอดีกับแต่ละแถว (และมีเพียงหนึ่งแถวในแต่ละบล็อก) อย่างน้อยก็เป็นเหตุผลทางประวัติศาสตร์สำหรับมัน ทุกวันนี้คนส่วนใหญ่มองว่าการทำแบบนี้เป็นการทำ sub-optimization

— อาหารเหลว
แหล่งที่มา