เหตุใดจึงไม่มีประเภทจำนวนเต็มที่ไม่ได้ลงชื่อในแพลตฟอร์มฐานข้อมูลด้านบน

ฐานข้อมูลมักจะปรับแต่งได้มากด้วยชนิดข้อมูลที่แตกต่างกันและความยาวที่กำหนดเอง

มันทำให้ฉันประหลาดใจเนื่องจากฉันพยายามค้นหาไวยากรณ์เพื่อใช้unsigned intชนิดที่ไม่สามารถใช้ได้จากทั้ง PostgreSQL และ MS SQL Server MySQL และ Oracle ดูเหมือนจะ

ดูเหมือนว่าการละเลยที่เห็นได้ชัดในส่วนของพวกเขา - ตัวเลือก perfomant ที่ดีที่สุดถัดไปคือ long / bigint, (จำนวนเต็ม 8 ไบต์) แต่อาจไม่จำเป็นอย่างสมบูรณ์! ไม่มีใครรู้ว่าทำไมพวกเขาถึงเลือกที่จะไม่รวมการสนับสนุน int แบบไม่ได้ลงนาม?

sql-server postgresql datatypes

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

แบบพกพา == มาตรฐานบังคับ มาตรฐาน C ไม่ได้ระบุความกว้างของ int หรือ longs ธรรมดาเพียงช่วงต่ำสุดของตัวเลขที่สามารถแทนได้ แพลตฟอร์มที่มี 16 บิต int เป็นเรื่องธรรมดาในบางจุด 64 บิตเป็นไปได้ 36 ด้วย (แม้ว่าสูญพันธุ์) 24 เกิดขึ้น (DSP) บ่อยครั้งแค่ไหนที่คุณมีข้อมูลที่พอดีใน 32 บิต แต่ไม่ใช่ 31 และคุณวัดว่าการใช้ประเภทตัวเลขทั่วไปจะทำให้คุณได้รับประสิทธิภาพหรือไม่

— จ้า

ทั้ง SQL-Server และ Postgres มีNUMERIC(10)จำนวนเต็มถึง9.999.999.999(และมีข้อ จำกัด คุณสามารถไม่อนุญาตให้ใช้ค่าลบ)

— ypercubeᵀᴹ

ด้วยเหตุผลหนึ่งข้อ: พวกเขาไม่ได้ระบุไว้ในมาตรฐาน SQL สำหรับการสนทนาที่ยาวนานขึ้นเกี่ยวกับ Postgres ลองดูที่การสนทนานี้: postgresql.1045698.n5.nabble.com/และสิ่งนี้: postgresql.1045698.n5.nabble.com/…

— a_horse_with_no_name

สำหรับ SQL Server คำอธิบายอยู่ที่นี่

— Martin Smith

@ แมทมันไม่ใช่การแสดงที่ฉันกังวลเกี่ยวกับมันเป็น 4 ไบต์พิเศษ x 153 ล้าน = ~ 612 พิเศษ MB เสียค่าไป 3 พันล้าน แต่ไม่ใช่ 4 พันล้าน ตัวเลข (10) แสดงผลงานฮิตนอกเหนือจากการกำหนดให้มีพื้นที่เก็บข้อมูล 9 ไบต์: msdn.microsoft.com/en-us/library/ms187746.aspx

— Ehryk

Jim Hogg ของ Microsoft ได้ตอบปัญหานี้แล้วดังนี้

มีข้อดีและข้อเสีย ด้านโปรดูเหมือนว่าจะเป็นวิธีที่ดีในการหลีกเลี่ยงข้อผิดพลาดบางอย่างโดยต้องตรวจสอบ int (ที่ลงชื่อ) มีค่า> 0 และฉันก็อยากจะใช้การใช้ int จำนวนมากในความเป็นจริงที่เกี่ยวข้องกับการนับ . คำถามเกี่ยวกับการเพิ่มจำนวนแถวสูงสุดเป็นสองเท่า? - จริง แต่ฉันจะบอกว่านี่น่าสนใจน้อยกว่า

ด้านข้อเสีย ... การผสมประเภทที่มีลายเซ็น / ไม่ได้ลงนามใน C หรือ C ++ ดูเหมือนว่ามันควรจะง่ายพอ มันไม่ใช่. มันเปิด tarpit ขนาดเล็กของข้อผิดพลาดที่หายาก - ส่วนใหญ่เนื่องจากกฎที่ซับซ้อนสำหรับโปรโมชั่น / widen นัย SQL, อนิจจา, มีชุดกฎการคัดเลือกที่ซับซ้อนยิ่งขึ้น ฉันกลัวว่าการเพิ่ม ints ที่ไม่ได้ลงนามจะทำให้พวกเราสับสนมากยิ่งขึ้น

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

ที่มา: Microsoft Connect

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

ลิงค์ Connect เดิมโพสต์โดยMartin Smithในความคิดเห็นคำถาม

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

"ทำให้เราสับสนมากยิ่งขึ้น" - อาจหมายถึงทุกคนที่ใช้ SQL Server ไม่ใช่แค่ทีมพัฒนาของตัวเอง

— Oskar Berggren