创建可伸缩的数据库架构以存储高尔夫分数

Question

I am trying to design a database to store all my friends and my golf scores. As you probably know, a golf score is comprised of 18 hole individual scores. I can think of two ways to design the schema:

1. Create a table that has one column for each hole (eg h1 to h18), the table has FK player_id, round_id and course_id that referenced other tables. It has a total column, which is the sum of columns h1 to h18. If I change a hole score, I will need to manually update total column.

2. Create a table that has a column for hole score, a column for hole index, a column for player_id, course_id, and round_id. To get the total score for a round, I will need to do a SUM query on round_id, player_id.

For now, the database would probably store scores from less than 20 people, so either approach should be fine. But what if I want to store scores for 20,000 people, which approach is more scalable?

I am using MySQL 5, with PHP5. Thanks.

Update> Examples of queries: 1. Reading the 9/18 scores from all players for a round and building a scorecard. 2. Basic stats like finding the lowest/average/highest total scores for a player for the last X rounds. 3. More advanced stats like average score of any hole for the last X rounds.

Answer 1

What was my average, highest and lowest score?

Scenario 1.

select (h1+h2+h3+h4+h5+h6+h7+h8+h9+h10+h11+h13+h14+h15+h16+h17+h18) / 18 as avg_score
      ,greatest(h1,h2,h3,h4,h5,h6,h7,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18) as highest
      ,least(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18) as lowest
  from scores
 where player_id = 1;

vs.

select avg(score) as avg_score
      ,max(score) as highest
      ,min(score) as lowest
  from scores
 where player_id = 1;

Which hole was my worst?

Scenario 2.

select case when h1 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18)  then 'H1'
            when h2 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18)  then 'H2'
            when h3 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18)  then 'H3'
            when h4 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18)  then 'H4'
            when h5 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18)  then 'H5'
            when h6 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18)  then 'H6'
            when h7 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18)  then 'H7'
            when h8 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18)  then 'H8'
            when h9 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18)  then 'H9'
            when h10 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18) then 'H10'
            when h11 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18) then 'H11'
            when h12 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18) then 'H12'
            when h13 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18) then 'H13'
            when h14 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18) then 'H14'
            when h15 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18) then 'H15'
            when h16 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18) then 'H16'
            when h17 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18) then 'H17'
            when h18 = greatest(h1,h2,h3,h4,h5,h6,h8,h8,h9,h10,h11,h12,h13,h14,h16,h17,h18) then 'H18'
        end as hole_highest_score      
  from scores
 where player_id = 1;

vs.

select hole, score
  from scores s1
 where player_id = 1
   and score = (select max(score)
                  from scores s2
                 where s2.player_id = s1.player_id)

I would go with scenario 2 any day :)

Answer 2

Even though the second approach is my preferred one, since the rules of Golf probably won't change very often, the first design could work in this case. The sum column, if you would choose to have one, could be computed with a trigger.

However, you would have to handle the situation when you and your friends decide to go a 9-hole or a 36-hole round. There is also the issue with how to store additional per-hole information, in case there are any. A schema with a separate table with a row for each hole played by a player will be much easier to maintain.

As always, the best solution depends on how you are going to use, update and query the data. If your only use case involves displaying total scores and high scores, the first approach could work.

As soon as a use case is to deal with information related to a particular hole, your application code and/or SQL will be harder to write and maintain. Take for instance getting the average score for a particular hole for all games played.

In any case I would suggest going with the second alternative and store per-hole scores in a separate table. The performance benefits of having all scores in the same table will probably not outweigh the troubles with maintaining it and writing queries towards it.