Cách tốt nhất để thiết kế cơ sở dữ liệu giải đấu


13

Tôi đang tạo một trang web để đặt cược vào tất cả các trận đấu của giải bóng đá Euro 2012 sắp tới. Cần một số trợ giúp để quyết định cách tiếp cận nào cho giai đoạn loại trực tiếp.

Tôi đã tạo ra một mockup bên dưới, điều mà tôi khá hài lòng khi lưu trữ kết quả của tất cả các trận đấu vòng bảng "đã biết". Thiết kế này giúp bạn dễ dàng kiểm tra xem người dùng đã đặt cược đúng hay chưa.

Nhưng cách tốt nhất để lưu trữ các trận tứ kết và bán kết là gì? Những trận đấu đó phụ thuộc vào kết quả ở vòng bảng.

Một cách tiếp cận tôi nghĩ đến là thêm TẤT CẢ các trận đấu vào matchesbảng, nhưng chỉ định các biến hoặc số nhận dạng khác nhau cho các đội nhà / sân khách cho các trận đấu trong giai đoạn loại trực tiếp. Và sau đó có một số bảng khác với các số nhận dạng được ánh xạ tới các nhóm ... Điều này có thể hoạt động, nhưng không cảm thấy đúng.

Thiết kế cơ sở dữ liệu cơ bản


Bạn đã quyết định sử dụng MySQL hoặc mở cho các lựa chọn thay thế?
Jack nói hãy thử topanswers.xyz

Đã giải quyết được khá nhiều .. Có bất kỳ lợi thế / bất lợi nào với MySQL mà tôi nên biết không?
hampusohlsson

Kiểm tra các ràng buộc không được thi hành. Nói chung, ít tùy chọn hơn để thực thi các ràng buộc với DRI - nhưng liệu điều đó có quan trọng với bạn hay không phụ thuộc rất nhiều vào ứng dụng của bạn. Rất vui được trò chuyện nếu bạn muốn có thêm ý kiến ​​:)
Jack nói hãy thử topanswers.xyz

Cảm ơn, nhưng tôi không nghĩ rằng dù sao tôi cũng sẽ sử dụng các ràng buộc vì tôi không quen lắm với nó. Sẽ xác thực tất cả dữ liệu trong ứng dụng của tôi trước khi được gửi tới DB, giữ cho nó đơn giản
hampusohlsson

Tốt tốt. Tất nhiên là đơn giản hơn trong DB nhưng đó là một cuộc trò chuyện hoàn toàn khác ;)
Jack nói hãy thử topanswers.xyz

Câu trả lời:


3

Tôi đã bắt đầu bằng cách cố gắng sửa tất cả các thông tin được xác định trước trong chính mô hình bao gồm

  • ngày / địa điểm
  • cấu trúc (tức là giai đoạn nhóm / loại trực tiếp)
  • quy tắc (tức là tính điểm, quy tắc hòa vốn)

Một số thông tin này sẽ là dữ liệu trong các bảng, một số sẽ được mã hóa logic trong các khung nhìn.

Một cái gì đó như thế này có lẽ:

  • nhóm (team_id, group_code enum ('A', 'B', 'C', 'D'), tên)
  • trận đấu (match_id, kickoff_at)
  • nhóm_match (match_id, team_id_home, team_id_away, group_code)
  • knoutout_match (match_id, knockout_code enum ('Q1', 'Q2', 'Q3', 'Q4', 'S1', 'S2', 'F')
  • kết quả (match_id, points_home, points_away)

Thông tin mà các đội chơi trong Q1 không bao giờ cần được lưu trữ trực tiếp vì có thể được tính từ kết quả vòng bảng. Những thay đổi duy nhất để thực hiện khi tiến trình giải đấu được chèn vào resultbảng.


3

Tôi nghĩ rằng sử dụng ID nhóm là cách đúng đắn. Một mức độ trừu tượng khác cho tất cả các vòng chung kết chỉ tăng thêm độ phức tạp không cần thiết vì không có nhiều lợi ích ngoài việc tải trước bảng khớp với dữ liệu.

Cấu trúc dữ liệu trông khá chắc chắn để hỗ trợ điều này. Vòng tứ kết và bán kết sẽ cần được thêm vào bảng trận đấu sau khi kết quả trận đấu ban đầu được đưa vào. Nếu các trận đấu được chỉ định ngẫu nhiên thì đây là một thao tác thủ công, tuy nhiên, nếu chúng theo thứ tự cụ thể ...

   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

... Sau đó, điều này có thể có thể được thực hiện với một truy vấn. Một lần nữa, độ phức tạp của truy vấn có thể không đáng để nỗ lực tùy thuộc vào số lượng đội


1

Đó là một ý tưởng tốt để lưu trữ tất cả các trận đấu trong bảng "trận đấu". Tuy nhiên tôi sẽ thêm "xếp hạng" trường quảng cáo vào nó, bởi vì sau này bạn cần nó để xây dựng cây nhị phân để truy vấn hiệu quả bảng trong bộ nhớ. Đây là một vấn đề thuật toán xếp hạng cổ điển và bạn có thể google cho giải đấu mã màu xám để biết thêm thông tin hoặc tìm trong lịch sử stackoverflow của tôi. Về cơ bản một giải đấu là một cây nhị phân. Đây là một bài viết hay về mã màu xám: http://villemin.gerard.free.fr/Wwwgvmm/Numerati/CodeGray.htmlm . Thật không may, nó là tiếng Pháp. Dưới đây là cách tạo cây nhị phân từ bảng xếp hạng: http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/229068 .

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.