database-design - 在数据库中存储(子)日志和(子)分类帐以用于会计应用程序

Question

在会计应用程序的许多不同实现中，有两种主要的数据库设计方法来保存日志和分类帐数据。

1. 只保留 Journal 信息，然后 Ledger 只是 Journal 的一个 View (因为 journal 总是比 ledger 保留更多的信息)

2. 将日记帐保存在单独的表中，然后将日记帐条目发布到分类帐表中，从而重复数据

3. 当涉及到子分类账/分类账时，有些实现将所有信息都放在一个分类账/分类账表中，然后使用会计科目表作为基础为不同的子分类账/分类账提供不同的 View

   <

4. 我看到人们为每个子期刊/分类帐设置了专门的表格，导致表格数量与特殊期刊类型(应收账款、应付账款、采购、销售等...)一样多。

目前，我的想法是，最多应该只有一个 Journal 和一个 Ledger 表，然后在查询时通过会计科目表中的定义来编译专门的日记账/分类账。我什至可能考虑仅使用 Journal 表，然后在查询时将分类帐编译为 Joirnals 的子集。

我想检查一下我是否遗漏了什么？有单独的日记帐和分类帐表是否有一些真正的原因，特别是，是否有理由拥有专门的日记帐 > 专门的分类帐 > 普通日记帐 > 总帐表，因为它似乎有很多数据重复、插入、更新、删除异常为什么我现在看不到？

Answer 1

主要原因可能是查询 SLA。从我的 POV 来看，我更喜欢使用 Journal 实体中的所有条目制作 3NF 数据模型。日记帐然后链接到分类帐、COA 等。通过这种方式，您可以使用 View 构建分类帐:在 3NF 模型上，您需要构建一个使用 View 制作的语义模型(可以是具有严格 SLA 的查询的物化 View )。

通过这种方式，您可以减少仅实现关键查询的重复，并为 future 与其他数据的集成/分析做好准备。