我担心我不知道我在做什么。数据库设计 - 关于效率的问题（和一般设计质量）

1：

我有一个表称为ticket具有称为total柱。当总数更新时，我想保留它的记录（旧总数等），所以我决定删除total列并创建一个名为ticket_total的表，其中列ticket_id,total和datetime（最近的当然是“当前”总数）。

或

2：

然后我意识到我会在后面想给我的客户通过total，排序票或拉手聚集总数，等等。所以，我决定，而不是报告的能力将total列放回ticket，并在更新总数时直接更改total列，但首先创建一个ticket_total行作为先前的total的记录。

看起来版本2会非常高效，因为我不需要尽可能多地查询相关的ticket_total表，但是我想知道你的数据库专家在那里想什么。我只是在学习数据库设计，并担心我永远不会擅长它。

来源

2010-10-04 orokusaki

我会与选项2，你有建议。

只要确保您正在执行事务中的更新（票证）+插入（在ticket_total中）以确保维持完整性。

来源

2010-10-04 03:27:12 InSane

谢谢。我目前使用Django的'@ transaction.commit_on_success'来包装创建两个记录的方法。你认为＃2是一种“好”的数据库设计实践吗？如果没有，我有完全的灵活性来改变它。 – orokusaki 2010-10-04 03:29:55

我会让ticket_total成为视图，而不是表格。我会创建另一个视图ticket_current，在那里我会根据最新日期过滤票证，即如果票证表在ticket_Id和datetime上双重键入。如果不是，则不顾最后一部分。

来源

2010-10-04 03:26:38 JoshRoss

第二种方法更快，但如果要创建总计历史值的报表，则应该有一个单独的表格，您可以将要替换的值与时间戳一起存储。这种类型的表被称为审计表。

来源

2010-10-04 03:36:48

谢谢格特 - 我不知道这是一个标准做法。这让我感觉自己更好，知道我意外执行了一个标准:) – orokusaki 2010-10-04 03:43:16

回复：“效率” - 最好不要太担心项目开始时的数据库效率问题。不成熟的优化是避免常见的错误。

更好的是专注于您的需求和设计给他们。之后，您可以测试以查看性能瓶颈在哪里并正在解决它们。对于较小的数据库（成千上万行），即使是“低效”查询，如果今天的服务器和软件经常变得非常快速，

保持简单我建议你避免组合键和重载表语义，除非你真的有这个需要。

提案您有两种类型的数据：当前票证信息和旧“总”值的历史记录表。

所以你的版本2将是首选。

ticket 
    id 
    field_a 
    field_b 
    total # current_total 

ticket_total # history of ticket total field 
    id 
    ticket_id 
    total 
    create_time

也 “总” 听起来像的东西聚集。我建议你试着想出一个更具描述性的字段名称。 - 场地总数是多少？ “total_worktime”？

添加记得为表添加索引。通过您用于查找的任何内容进行索引。例如，售票表是否有customer_id？确保它已被编入索引。

来源

2010-10-04 03:41:41

谢谢:)'total'确实听起来相当通用，不是。特别是当考虑到表中有17列时。 – orokusaki 2010-10-04 03:45:20

数据库设计 - 关于效率的问题（和一般设计质量）

1：

2：

回答

相关问题