构建数据库

时间:2013-11-05 23:35:31

标签: postgresql database-design relational-database yesod

在我的数据库中,我需要以下关系:

  • 锦标赛参赛者(Tpart)
    • 将用户与锦标赛联系起来
  • 圆形
    • 这是一场单场比赛
    • 将Tpart与圆形
    • 联系起来
    • 也有分数

这是我目前的持久实体:

Tournament
  name Text
  urlName Text
  location GolfCourseId
  startDate Day 
  endDate Day Maybe
  UniqueTName name
  UniqueTUrlName urlName

Tpart
  tournament TournamentId
  userId UserId  
  deriving Show
  deriving Eq

Round
  tourn TournamentId
  name Text
  UniqueRound tourn name
  deriving Show

Hole
  round RoundId
  part TpartId
  score Int 
  deriving Show

鉴于我需要进行的查询,我不知道这是否是最好的结构。 我需要

  • 获取每个Tpart的一轮总分 这可以通过总结与特定回合和Tpart相关的所有孔的得分来完成

    Part | round 1 | round 2 | ...  
    p1   | 56      | 54  
    p2   | 60      | 57  
    
  • 获取与圆形相关的所有洞和部分

    Part | hole 1 | hole 2| ...  
    p1   | 3      | 5  
    p2   | 5      | 6  
    

要获取第一个表格中的数据,需要将每个用户的所有洞穴分数相加。这是一种有效的方法吗?或者更好的是拥有另一个实体RndScore,如下所示:

RndScore
  rnd RoundId
  tpart TpartId
  score Int

每次更新钻孔实体时都可以更新此实体。这些解决方案中的任何一个看起来都相当强大

1 个答案:

答案 0 :(得分:2)

我的建议是:您应始终使用干净,规范化的逻辑关系数据库设计,而不存储冗余数据,并相信DBMS将足够好地获取您的数据(即,回答您的查询)。这就是DBMS的用途。下一步应该是优化您的物理数据库设计,例如,选择索引,表格存储参数等。根据您的数据库,您甚至可以实现您的视图,以便存储他们的结果实际上,在逻辑数据库设计中添加派生值(例如您的 RndScore 关系)应该是最后的选择,因为您必须手动确保它们的一致性。

通常,您应该避免过早优化:确保您确实需要优化数据库布局(例如,通过测量运行时,检查查询执行计划,估计您必须回答的查询数等,等等。)