วิธีที่ดีที่สุดในการออกแบบฐานข้อมูลทัวร์นาเมนต์


13

ฉันกำลังสร้างเว็บเพจสำหรับวางเดิมพันในการแข่งขันฟุตบอลยูโร 2012 ที่กำลังจะมาถึง ต้องการความช่วยเหลือในการตัดสินใจว่าวิธีการที่จะใช้สำหรับขั้นตอนการทำให้ล้มลง

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

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

วิธีหนึ่งที่ฉันคิดว่าจะเพิ่มการแข่งขันทั้งหมดลงในmatchesตาราง แต่กำหนดตัวแปรหรือตัวระบุต่าง ๆ ให้กับทีมเหย้า / ทีมเยือนสำหรับการแข่งขันในช่วงการทำให้ล้มลง และมีตารางอื่นที่มีตัวระบุเหล่านั้นแมปกับทีม ... วิธีนี้สามารถใช้งานได้ แต่รู้สึกไม่ถูกต้อง

การออกแบบฐานข้อมูลพื้นฐาน


คุณตัดสินใจใช้งาน MySQL หรือเปิดทางเลือกอื่นหรือไม่?
แจ็คบอกว่าลอง topanswers.xyz

ตัดสินค่อนข้างมาก .. มีข้อได้เปรียบ / ข้อเสียกับ MySQL ฉันควรระวัง?
hampusohlsson

ตรวจสอบข้อ จำกัด ที่ไม่ได้บังคับใช้ โดยทั่วไปตัวเลือกน้อยลงสำหรับการบังคับใช้ข้อ จำกัด กับ DRI - แต่ไม่ว่าเรื่องนั้นจะขึ้นอยู่กับคุณหรือไม่นั้นขึ้นอยู่กับแอปพลิเคชันของคุณ มีความสุขที่จะแชทถ้าคุณต้องการความคิดเห็นเพิ่มเติม :)
แจ็คพูดว่าลอง topanswers.xyz

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

ดีดี. มันง่ายกว่าในฐานข้อมูลแน่นอน แต่นั่นเป็นการสนทนาอื่นทั้งหมด ;)
แจ็คพูดว่าลอง topanswers.xyz

คำตอบ:


3

ฉันจะเริ่มต้นด้วยการพยายามแก้ไขข้อมูลที่กำหนดไว้ทั้งหมดในตัวแบบรวมถึง

  • วันที่ / สถานที่จัดงาน
  • โครงสร้าง (เช่นกลุ่ม / ขั้นตอนการทำให้ล้มลง)
  • กฎ (เช่นการให้คะแนนคะแนน, กฎการเสมอกัน)

ข้อมูลบางส่วนนี้จะเป็นข้อมูลในตารางบางส่วนจะถูกประมวลผลตรรกะในมุมมอง

บางสิ่งเช่นนี้อาจจะ:

  • ทีม (team_id, group_code enum ('A', 'B', 'C', 'D'), ชื่อ)
  • การแข่งขัน (match_id, kickoff_at)
  • group_match (match_id, team_id_home, team_id_away, group_code)
  • knockout_match (match_id, knockout_code enum ('Q1', 'Q2', 'Q3', 'Q4', 'S1', 'S2', 'F')
  • ผลลัพธ์ (match_id, score_home, score_away)

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


3

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

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

   A
match 1 -----+
   B         A
          match 5 -----+
   C         C         |
match 2 -----+         |
   D                   A
                    match 7
   E                   F
match 3 -----+         |
   F         F         |
          match 6 -----+
   G         G
match 4 -----+
   H

... ถ้าอย่างนั้นก็สามารถทำได้ด้วยแบบสอบถาม อีกครั้งความซับซ้อนของแบบสอบถามอาจไม่คุ้มค่ากับความพยายามขึ้นอยู่กับจำนวนทีม


1

เป็นความคิดที่ดีที่จะเก็บการแข่งขันทั้งหมดในตาราง "การแข่งขัน" อย่างไรก็ตามฉันจะเพิ่ม "การจัดอันดับ" ในฟิลด์ aditional เพราะในภายหลังคุณจำเป็นต้องสร้างแผนภูมิแบบทวิภาคเพื่อสืบค้นตารางในหน่วยความจำอย่างมีประสิทธิภาพ มันเป็นปัญหาของอัลกอริทึมการจัดอันดับแบบคลาสสิกและคุณสามารถ google สำหรับทัวร์นาเมนต์รหัสสีเทาสำหรับข้อมูลเพิ่มเติมหรือดูในประวัติ stackoverflow ของฉัน โดยทั่วไปการแข่งขันเป็นต้นไม้ไบนารี นี่เป็นบทความที่ดีเกี่ยวกับรหัสสีเทา: http://villemin.gerard.free.fr/Wwwgvmm/Numerati/CodeGray.htm น่าเสียดายที่มันเป็นภาษาฝรั่งเศส นี่คือวิธีการสร้างต้นไม้ไบนารีจากการจัดอันดับ: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/229068

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