数据库设计中的财政年度处理策略

时间:2010-03-13 23:43:12

标签: database performance database-design

到会计年度,我指的是特定年份中发生的数据库(在所有表格中)的所有数据。假设我们正在构建一个允许用户从不同年份中进行选择的应用程序。

您希望采用何种方式实现此目标,以及为什么:

  1. 基于多个单独的数据库实例分隔会计年度数据(例如,在每个会计年度开始时,您可以创建一个没有数据的新实例)
  2. 将所有内容放在一个数据库中,但使用逻辑自动分隔不同年份的记录。
  3. 就个人而言,我已“看到”这两种方法,我会选择第二种方法。对于第一种方法,我能想到的唯一一个参数就是在这些数据库真的很大的情况下记录较少的记录 - 但是,你仍然可以通过加入摘要或其他方式来“归档”旧记录。你觉得怎么样?

4 个答案:

答案 0 :(得分:3)

  

基于多个单独的数据库实例分隔会计年度数据(例如,在每个会计年度开始时,您可以创建一个没有数据的新实例)

没有。 每个会计年度创建一个单独的数据库实例,数据库或表。

除了没有正常化之外,您将不必要地重复支持基础设施:约束,触发器,存储过程和必须更新 所有 的功能才能使用新的当前会计年度。这也会使未来几年的预算和规划数据复杂化。

  

将所有内容放在一个数据库中,但使用逻辑自动分隔不同年份的记录。

不需要分离,只需确保记录包含时间戳,然后可以用它来确定它发生在哪个会计年度。

答案 1 :(得分:3)

无需重复。时间戳可能已经足够好了,但是从数据仓库借用,您可以创建“日期维度”。它是一个每天有一行和每个日期列属性的表。其中一些列可能是会计年度,财务季度等。然后您将DateKey添加到事务表并在查询时加入日期维度。

类似的东西:

select sum(t.Total)
from Transactions as t
join dimDate as d on d.DateKey = t.DateKey
where d.FiscalYearQuarter = 'F2009-Q3';

日期维度表可能类似于:

CREATE TABLE dimDate
  ( 
   DateKey int                      -- 20090814
  ,FullDate date                    -- 2009-8-14
  ,FullDateDescription varchar(50)  -- Friday August 14, 2009
  ,SQLDateStamp varchar(10)         -- 2009-08-14
  ,DayOfWeek varchar(10)            -- Friday
  ,DayNumberInWeek int              -- 6
  ,DayNumberInMonth int             -- 14
  ,DayNumberInYear int              -- 226

  -- many more here

  ,FiscalYear int                   -- 2009
  ,FiscalQuarter char(3)            -- FQ3
  ,FiscalHalf char(3)               -- FH2
  ,FiscalYearQuarter varchar(8)     -- F2009-Q3
  ,FiscalYearHalf varchar(8)        -- F2009-H2 
  );

您可以预先加载dimDate,从过去的转发到将来的转发; 100年需要36.5k行 - 对任何数据库来说都不多。

答案 2 :(得分:2)

还有第三种选择。

创建一个表,我们称之为“Almanac”,每天有一行,按日期键入。 在该表中,您可以拥有由日期确定的大量属性。 其中可能是某些功能,如星期几。某些属性可能是公司特定的,例如该日是否是公司的工作日。

如果贵公司有这样的事情,那么属性可能是财政年度,财政季度和财政月份。规范化此表并不是特别重要。

编写一个填充此表的程序。因此,从日期开始计算财政年度的所有复杂逻辑可以在一个地方,而不是分散在整个系统中。十年的日期只有大约3,650排,这是今天标准的一张小桌子。

然后,按财政年度,财政季度或其他任何方式削减所有日期驱动数据只需加入和分组。您甚至可以自动生成相同数据的不同时间帧视图。

我已经完成了这项工作。它在报告数据库和数据仓库方面特别好。

答案 3 :(得分:1)

每个实体都应将其会计年度作为元数据/静态数据的一部分。

由此您可以轻松处理会计年度休息时间,通常数据库可以处理非常大量的数据,因此您不应该遇到问题。

使用正确的索引将极大地提高查询的性能,因此一旦遇到问题就要担心性能问题。 在此之前,担心代码