我被要求创建一些跟踪帐户收集的每日成本的东西,我试图找出一个支持这个的数据库表模式.
这就是我所知道的
>公司拥有超过250万个账户
>其中,他们目前平均每月工作200,000(随着人员配置水平的变化,目前很低)
>他们有13种不同的成本类型,他们希望跟踪,他们警告说,未来可能会增加更多
>他们希望每天跟踪成本
>成本不会分散在整个库存中.它们或者分成每月工作的帐户数(200,000),或者用户可以输入帐户标识符以将成本应用于一组帐户,或者他们可以简单地指定要应用成本的帐户.
我的第一个想法是规范化的数据库：
- AccountId
- Date
- CostTypeId
- Amount
我的问题是,算一算.这张桌子很快就会变得很快.假设所有13种成本类型都适用于当月的所有工作账户,即每月20万* 13 * N天,即每月约75-80万条记录,或每年接近10亿条记录.
我的第二个想法是将它归一化
- AccountId
- Date
- TotalCost
- CostType1
- CostType2
- CostType3
- CostType4
- CostType5
- CostType6
- CostType7
- CostType8
- CostType9
- CostType10
- CostType11
- CostType12
- CostType13
这种方法更加非规范化,每月可创建多达600万条记录(每月200k * N天),或每年约7200万条记录.它比第一种方法少得多,但如果公司将来决定新的“成本类型”,则需要添加另一个数据库列.
在这两种方法中,您更喜欢哪种方法？为什么？还有另一种选择,您可以想到哪种方法可以更好地处理这种情况？
我最感兴趣的是报告性能,包括夏季报告和详细报告.如果没有人陪伴,那么将会在账户上分摊成本的工作将在每晚进行.第二个问题是数据库大小.现有数据库已经接近300GB,我相信磁盘空间大约为500GB.
解决方法
一年十亿的记录并不多.
通过分区(可能是每个Costtype)和归档,它是可管理的.
要存储的数据项数量仍然是200k * 13 * N.作为列,每页的行数会减少,占用的行数比行数要多.如果“CostType1”不是固定长度数据类型,则可能获得,但它是边缘的.
正如他们所说,“亲吻”
