【问题标题】:SQL Database Design Question: Many To One Relationship vs Full SeparationSQL 数据库设计问题:多对一关系与完全分离
【发布时间】:2019-05-10 14:07:34
【问题描述】:

我正在设计一个简单的数据库来存放两种类型的数据:

  • 任务(一个工作单元):与用户的多对一关系
  • 任务后聚合统计(关于已完成工作的聚合数据):与用户的一对一关系。

当前数据流的工作方式:在第一个表中创建许多任务,当它们完成时,计算一些任务后统计数据,然后将其附加(与一些公式聚合)到单个任务后聚合统计数据行具有相同用户的第二个表。然后删除原始任务。

为了清楚起见,这是一个带有数据值的示例:

任务:

{
  id: {uuid}
  user: {user_id}
  create_time: {timestamp}
  last_modified_time: {timestamp}
  description: {string}
  completion_time: {int}
  length: {int}
  difficulty: {int}
  cost: {int}
  ...
}

任务后聚合统计

{
  id: {uuid}
  user: {user_id}
  total_completed_tasks: {int}
  avg_completion_time: {double}
  avg_task_length: {double}
  avg_task_difficulty: {double}
  avg_task_cost: {double}
  ...
}

是否有更好/更智能的方法来设计此类数据的状态。我考虑过的事情:

  • 完成后不删除任务(只是将其标记为完成)并建立多(任务)对一(聚合统计)关系
  • 不聚合统计信息,在任务和个别岗位任务统计之间建立一对一的关系,然后查询统计表并根据需要进行聚合

【问题讨论】:

  • 这取决于您的具体需求。如果某项任务完成后你不关心它,那么删除它似乎是合理的。
  • @ZoharPeled - 使用我当前的功能集,我不需要它,但我将来可能需要数据。现在在预期中寻求更复杂的数据表示会被认为是过度设计吗?或者我应该在/如果我最终达到该功能时担心它。
  • “但我以后可能需要数据” 可能是这里的关键字。不要做你未来可能需要做的事,做你未来需要做的事。

标签: sql database-design relational-database


【解决方案1】:

如果您没有太多的容量可能会成为性能问题,我建议您不要将聚合统计信息具体化到表中,而是在 task 表的顶部创建聚合视图。这样,当您查询视图时,您的聚合就会动态计算,您不需要处理额外的聚合过程。

PostgreSQL 中的示例:

create or replace view task_statistics as
select user
, count(distinct id) as total_completed_tasks
, avg(completion_time) as avg_completion_time
, avg(length) as avg_task_length
, avg(difficulty) as avg_difficulty
, avg(cost) as avg_cost
from task
group by user;

【讨论】:

  • 感谢您的建议,这肯定会降低复杂性。
  • @ThomasChen 我刚刚格式化了答案,之前我不能这样做,因为我是从手机上发布的。现在应该更清楚了。如果您认为它可以解决您的问题,请考虑将其标记为答案。谢谢。
猜你喜欢
  • 1970-01-01
  • 2010-09-14
  • 1970-01-01
  • 2015-10-26
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2015-01-20
  • 1970-01-01
相关资源
最近更新 更多