ใช้ปุ่มลบเพื่ออะไร


12

ค่อนข้างใหม่ในการใช้ฐานข้อมูล SQL มาตรฐาน (ปัจจุบันทำงานกับ MySQL เป็นส่วนใหญ่) ฉันยังไม่ได้ใช้ในการใช้งานมากมายในตอนนี้

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


5
ก่อนอื่นใครก็ตามที่กำลัง downvoting โดยไม่แสดงความคิดเห็นคุณกำลังก่อความเสียหาย ต่อไปคำตอบสำหรับคำถามที่ยอดเยี่ยมนี้
jcolebrand

1
เรื่องนี้น่าสนใจ ฉันไม่เคยได้ยินแนวคิดนี้เป็นการส่วนตัว คำถามนี้ไม่ควรถูกลดลง +1 จากฉันสำหรับแนะนำแนวคิดนี้
RolandoMySQLDBA

คำตอบ:


13

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

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

ทำไมถึงมีประโยชน์ที่จะมี "คีย์ลบ" ในตารางนั่นเป็นคำถามเดียวกันกับ "ทำไมจึงมีประโยชน์ในการมีคีย์ในตาราง" "ค่า" ของคีย์ไม่มีผลกระทบต่อสถานะของคีย์ กุญแจคือกุญแจคือกุญแจ

สิ่งสำคัญคือถ้าคีย์นั้นถูกต้อง

ทำไมจึงเป็นประโยชน์ในการอนุญาตให้ใช้คีย์ที่เป็นลบฉันสามารถแนะนำเหตุผลบางอย่าง:

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

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

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


แก้ไขบิตของ 'โพรงที่เกิดขึ้น' เนื่องจากมีแนวโน้มที่จะเกิดความเข้าใจผิดมากขึ้นเนื่องจากไม่มีประสบการณ์ อ่านน่าสนใจ ฉันค่อนข้างจินตนาการว่าจะมีสถานการณ์ที่ค่าลบของคีย์มีประโยชน์อย่างใดในการเขียนโค้ด (i, e โดยไม่ต้องตัดสินใจว่ามันหมายถึงสิ่งใดก็ตาม) แต่นี่เป็นการคิดที่มีประโยชน์มากเมื่อคุณแบ่งแผนกออกเป็นสองกลุ่ม ไม่ต้องการใช้บูลเสริม: p
Garet Claborn

1
@Garet ~ คุณทำจุดดี: "คุณค่าของคีย์นั้นมีประโยชน์ในการเขียนโค้ด" และฉันใช้กุญแจของฉันเป็นครั้งคราวในลักษณะนั้น แต่มันไม่มีส่วนเกี่ยวข้องกับฐานข้อมูล ฐานข้อมูลเป็นคลังเก็บสินค้า แอปพลิเคชันที่ใช้ข้อมูลจะคำนึงถึงค่าต่างๆ แต่ใช่ว่า +/- บูลีนเป็นกลลวงที่เรียบร้อยฉันได้เห็นมันใช้เวลาหลายครั้งในการสร้างเอฟเฟกต์
jcolebrand

2
-1 สำหรับการอ้างว่าค่าการกำหนดคู่แบบนี้เป็นสิ่งอื่นที่ไม่ใช่ความคิดที่ไม่ดี คุณต้องการ int และบูลหรือไม่? ใช้ int และบูล
แจ็คบอกว่าลอง topanswers.xyz

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

1
@JackPDouglas ~ ฉันใช้ตัวอย่างเฉพาะเพราะมีเว็บไซต์ที่รู้จักกันดีมาก (เครือข่ายของไซต์) ที่คุณอาจเคยได้ยินมาว่ามันทำสิ่งนั้นมากดังนั้นฉันไม่ต้องการถูกไล่ออกเพราะมันเป็นสิ่งที่ถูกต้อง "เคล็ดลับ" ตรวจสอบผู้ใช้นี้dba.stackexchange.com/users/-1/communityและบอกฉันว่า ID ของเขาคืออะไร ฉันเกือบจะมั่นใจได้ว่าหมายเลขผู้ใช้เป็นคีย์หลัก (และในตารางอื่น ๆ เป็นต่างประเทศ) ที่สำคัญ เพียงเพราะแอปพลิเคชันไม่ดีสำหรับคุณไม่ได้หมายความว่ามันไม่ถูกต้อง แต่อีกครั้งนั่นไม่ใช่การออกแบบ db นั่นคือการออกแบบโดเมน ได้รับตรรกะ db สนับสนุนแล้ว
jcolebrand

10

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

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

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


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

@JackPDouglas: คุณไม่ได้ใช้เพื่อทำซ้ำเพื่อหลีกเลี่ยงการสร้างค่าบนเว็บไซต์ที่ผิด
gbn

พร้อมกับข้อ จำกัด การตรวจสอบ ? นอกจากนี้ยังมีอะนาล็อก MySQL (หรืออื่น ๆ ) NOT FOR REPLICATIONที่คุณรู้หรือไม่?
แจ็คบอกว่าลอง topanswers.xyz

@JackPDouglas: ขออภัยไม่แน่ใจเกี่ยวกับที่ไม่ใช่ SQL Server
GBN

8

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

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

การไม่สนับสนุนประเภทจำนวนเต็มที่ไม่ได้ลงนามอาจเป็นการตัดสินใจออกแบบตามการลดความซับซ้อน - เช่นไม่ต้องการชนิดจำนวนเต็ม 32 บิตสองชนิดที่แตกต่างกันเพื่อกังวลเกี่ยวกับการตรวจสอบช่วงเมื่อกำหนดค่าระหว่างพวกเขา มัน จำกัด จำนวนดัชนีที่เป็นไปได้ในฟิลด์การเพิ่มอัตโนมัติโดยเริ่มจาก 0 หรือ 1 ถึงครึ่งสิ่งที่เป็นไปได้ในประเภทที่ไม่ได้ลงนาม (~ 2e9 มากกว่า ~ 4e9) แต่นี่ไม่ค่อยเป็นปัญหาสำคัญ (ถ้าคุณต้องการ จำนวนของค่าคีย์ของขนาดนั้นคุณอาจไปสำหรับชนิด 64 บิตต่อไปโดยเฉพาะอย่างยิ่งถ้าใช้สถาปัตยกรรม 64 บิตซึ่งค่าดังกล่าวจะถูกประมวลผลอย่างมีประสิทธิภาพไม่น้อยกว่านั้นเป็น 32- บิต) แต่ถ้าคุณต้องการเต็มช่วงและต้องการ เพื่อยึด 32 บิตด้วยเหตุผลด้านพื้นที่คุณสามารถเริ่มเพิ่มได้ที่ -2,147,483,647


ใช่ฉันคิดว่าเราเคยพูดถึงเรื่องนี้มาก่อนแล้ว) tehehe dba.stackexchange.com/questions/983/…
jcolebrand

Tinyint ไม่ได้ลงนาม (0 .. 255) ฉันมักจะสร้างข้อ จำกัด ตรวจสอบในคอลัมน์จำนวนเต็มเพื่อให้แน่ใจว่ามีค่าไม่ติดลบตั้งแต่ย่อมรหัสจะถูกเขียนโดยปริยายที่ถือว่าแปลกและข้อบกพร่องที่จะเกิดขึ้นถ้าอย่างใดครีพค่าลบใน.
เอ็ด Avis
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.