数据库设计 - 关于效率(和总体设计质量)的问题
我担心我不知道自己在做什么。
1:
我有一个名为 ticket
的表,其中有一列名为 total
。当总计更新时,我想保留它的记录(旧总计等),因此我决定删除 total
列并创建一个名为 ticket_total
的表,其中包含列ticket_id
、total
和 datetime
(最新的当然是“当前”总计)。
或
2:
然后我意识到我以后希望让我的客户能够按总计
对工单进行排序,或者提取汇总总计的报告等。因此,我决定放回< ticket
上的 code>total 列,并在更新总计时直接更改 total
列,但首先创建一个 ticket_total
行作为先前总计
的记录。
看来版本 2 会非常高效,因为我不需要太多查询相关的 ticket_total
表,但我想知道你们的数据库专家是怎么想的。我正在学习数据库设计,担心我永远不会擅长它。
I fear I don't know what I'm doing.
1:
I have a table called ticket
which has a column called total
. When the total is updated I want to keep a record of it (old total, etc), so I decided to remove the total
column and create a table called ticket_total
with columns ticket_id
, total
, and datetime
(the most recent of course is the "current" total).
or
2:
Then I realized that I will later want to give my clients the ability to sort tickets by total
, or pull reports that aggregate the totals, etc. So, I decided instead to put back the total
column on ticket
, and to change the total
column directly when the total is updated, but first create a ticket_total
row as a record of the previous total
.
It seems that version 2 would be highly efficient because I wouldn't need to query the related ticket_total
table as much, but I wonder what you DB gurus out there think. I'm just learning database design and fear I'm never going to be good at it.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
我会选择您建议的选项 2。
只需确保您在事务中执行更新(票证)+插入(在 Ticket_total 中),以确保保持完整性。
I would go with option 2 that you have suggested.
Just make sure that you are doing the Update (of ticket) + Insert ( in ticket_total ) in a transaction to ensure that the integrity is maintained.
第二种选择速度更快,但如果您想创建有关总计历史值的报告,您应该有一个单独的表,在其中存储要替换的值和时间戳。这种类型的表称为审计表。
Your second alternative is faster, but if you want to create reports on historic values of the total, you should should have a separate table where you store the value you're replacing together with a timestamp. This type of table is referred to as an audit table.
回复:“效率”——最好是在项目开始时不要过多担心数据库效率。过早优化是一个需要避免的常见错误。
更好的方法是关注您的需求并针对它们进行设计。稍后,您可以测试看看性能瓶颈是否存在并致力于解决它们。
对于较小的数据库(数万行),考虑到当今的服务器和软件,即使是“低效”查询也通常会非常快。
保持简单 我建议您避免组合键和重载表语义,除非您确实有需要。
提案 您有两种类型的数据:当前工单信息和旧“总计”值的历史表。
所以你的版本 2 会是首选。
此外“总计”听起来像是某物的聚合。我建议您尝试想出一个更具描述性的字段名称。 -- 该字段总共是多少? “总工作时间”?
已添加 请记住为表添加索引。按您用于查找的任何内容建立索引。例如,ticket 表有 customer_id 吗?确保它已编入索引。
Re: "efficiency" -- best is to not worry too much about database efficiency at the beginning of a project. Premature optimization is a common mistake to avoid.
Better is to focus on your needs and design to them. Later, you can test to see if where the performance bottlenecks are and work on solving them.
For smaller databases (tens of thousands of rows), even "inefficient" queries often go very fast given todays' servers and software.
Keep it simple I suggest that you avoid combination keys and overloading table semantics unless you really have the need.
Proposal You have two types of data: current ticket information, and a history table for old "total" values.
So your ver 2 would be preferred.
Also "total" sounds like an aggregation of something. I suggest that you try to come up with a field name that is more descriptive. -- What is the field a total of? "total_worktime" ?
Added Remember to add indexes for the tables. Index by anything that you use for finds. Eg does the ticket table have a customer_id? Be sure that it's indexed.
我会让 Ticket_total 成为一个视图,而不是一个表。我将创建另一个视图 Ticket_current,在其中按最新日期过滤票证,即票证表是否在 Ticket_Id 和日期时间上采用双键。如果没有,请忽略最后一部分。
I would make ticket_total a view, not a table. I would create another view ticket_current where I would filter the tickets by the latest date, that is if the ticket table is dual keyed on ticket_Id and datetime. If not, disregard that last part.