0

tl;博士关于处理数据库数据和设计的一般问题：

在某个时间点从其他数据中派生数据是否可以接受/是否有任何缺点，然后将该派生数据存储到单独的表中以保留该特定时间的值历史记录，或者，如果您从不存储从其他数据派生的数据，而是仅在需要时从现有数据中派生所需数据？

我的具体情况：

我们有一个数据库，我们在其中记录人们的假期和假期状态。我们跟踪他们还剩多少天，他们花了多少天，诸如此类。

一项设计要求发生了变化，现在要求我能够显示一个人在任何给定年份的 12 月 31 日还剩下多少天。所以我需要能够说，“鲍勃在 2010 年 12 月 31 日还剩 14 天”。

我们可以通过两种方式做到这一点：

  1. 一个 SQL Server 代理作业，它在 12 月 31 日捕获当时每个人的剩余天数，并将它们插入到类似“YearEndHistories”的表中，该表将包含您当时的 EmployeeID、Year 和 DaysRemaining。

  2. 我们不保留 YearEndHistories 表，但是如果我们想找出在某个时间拥有的天数，我们会循环遍历在该特定时间之前存在的所有添加和减去的假期。

我喜欢 #1 带来的确定感 --- 记录的值将由管理部门审查，并且不会争论或改变该数字的可能性。使用 #2，我喜欢效率 --- 需要维护的表少了，并且实际表中不存在派生数据。但是我有一种奇怪的恐惧，担心一些看不见的错误会溜走，人们的历史价值计算会开始搞砸等等。2020年我不想处理，“我以9.5天结束2012，而不是9.0！我的半天去哪儿了？！”

我们已经决定的一件事是不能修改前几年的值。这意味着永远不可能回到上一个日历年并添加假期或类似的东西。年末的值就是THE值，不管过去有没有过错。如果发现错误，将通过奖励或减去当年的休假时间来弥补。

4

2 回答 2

4

是的，这是可以接受的，特别是如果计算复杂或经常调用，或者不经常更改（例如：游戏中的高分表 - 经常查看，但内容仅在越来越少的情况下更改一个球员做得很好）。

作为一般规则，我会尽可能规范化数据，然后出于性能原因在必要时添加派生字段或表。

在您的情况下，计算似乎相对简单 - 员工休假天数的总和 - 休假天数，但这取决于您。

顺便说一句，我鼓励您在涉及数据时不要考虑“循环”——尝试将数据作为一个整体来考虑，作为一个集合。就像是

SELECT StaffID, sum(Vacation)
from
(
    SELECT StaffID, Sum(VacationAllocated) as Vacation 
    from Allocations
    where AllocationDate<=convert(datetime,'2010-12-31' ,120)
    group by StaffID
    union
    SELECT StaffID, -Count(distinct HolidayDate) 
    from HolidayTaken
    where HolidayDate<=convert(datetime,'2010-12-31' ,120)
    group by StaffID
) totals
group by StaffID
于 2012-09-27T08:23:40.140 回答
0

派生数据在我看来就像一个传递依赖，这在规范化中被避免了。这是一般规则。
在您的情况下，我会选择＃1，它可以为您提供更好的“可审计性”，而不会降低性能。

于 2012-09-27T08:30:50.337 回答