ฉันควรแสดงชนิดที่แจกแจงในฐานข้อมูลเชิงสัมพันธ์ได้อย่างไร?

12

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

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

หมายเหตุ: ฐานข้อมูลที่เรากำลังใช้ไม่รองรับประเภทการแจงนับอย่างชัดเจน และซอฟต์แวร์ที่เรากำลังพัฒนาที่จะเชื่อมต่อกับฐานข้อมูลนี้เขียนใน C ++

database-design relational-database

— c.hughes
แหล่งที่มา

มันจะนัดหยุดงานคนอื่นนานเกินไปที่จะทำให้มันเป็นความหมายประเภทการตรวจสอบในการสร้างตาราง? สิ่งที่ชอบ: สร้างตาราง hit (ip varchar (40), ip_class ENUM (0, "IPv4", 1, "IPv6")); ควรอนุญาตให้คุณตรวจสอบ = <และ> ด้วยลำดับหรือสตริง (ที่แมปกับลำดับ)

— dlamblin

26

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

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

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

1

ใช่และถ้าคุณตัดสินใจว่าคุณต้องการเปลี่ยน 'O' เป็น 'Open' คุณจะต้องเปลี่ยนหนึ่งแถวเท่านั้น

— Daniel Kaplan

+1 ตาราง int / string ธรรมดาเป็นวิธีที่ดีที่สุดในการแสดง enums ในฐานข้อมูลเชิงสัมพันธ์

— mike30

น่าจะเป็นผู้เข้าชมต่อไปที่กำลังมองหาวิธีการแก้ปัญหา Java พบว่ามันมีประโยชน์

— Jauhien

2

นี้. สำหรับเครดิตพิเศษ - ถ้าทีม dev ได้กำหนดจำนวนเต็มใน Java / C # enum หรืออะไรที่คล้ายกันคุณสามารถเขียนการทดสอบที่ตรวจสอบว่านิยาม enum ของรหัสได้แยกออกจากตารางการค้นหาหรือไม่ มีอันตรายเสมอที่การเพิ่มองค์ประกอบตามลำดับสามารถทำให้สิ่งต่างๆหลุดจากการซิงค์และคุณไม่ทราบจนกว่าจะมีการบันทึกข้อมูลสดผิด

— Julia Hayward

4

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

ตัวอย่าง:

trans_type
----------
  รหัส
  ชื่อ

การทำธุรกรรม
------------
  รหัส
  trans_date
  รายละเอียด
  trans_type_id (FK ถึง trans_type.id)

ข้อมูลตัวอย่าง:

trans_type

ID | ชื่อ
----------
1 | SUBMIT
2 | ยกเลิก


การทำธุรกรรม

ID | trans_date | trans_type_id
---------------------------------
1 | 2012-12-31 | 1
2 | 2013-01-09 | 2

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

3

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

สิ่งนี้มีข้อดีเพิ่มเติมของการอัพเดตค่าสตริงในตำแหน่งที่ตั้งเดียวแทนที่จะเรียกใช้รูทีนการอัพเดตบางประเภท แทนที่จะเป็น 1 = 'สีแดง' ก็อาจเท่ากับ 'จริง ๆ สีแดง'

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

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

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

2

ฉันต้องไม่เห็นด้วยกับคำตอบอื่น ๆ สำหรับคำถามนี้ที่สนับสนุนวิธีการระบุตารางการแยกต่างหาก

อย่างไรก็ตามฉันชอบที่จะไม่ทำซ้ำสิ่งที่พูดไปแล้วดังนั้นฉันจะอ้างถึงคำตอบที่ยอมรับ (มากหรือน้อย) ของคำถามเดียวกันใน Stack Overflow: /programming//a/229919 / 114,626

— Eyal Roth
แหล่งที่มา

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

— Harke