在会计应用程序的许多不同实现中，涉及到保留日记帐和分类帐数据的数据库设计有2种主要方法。
仅保留日记帐信息，然后分类帐只是日记帐上的视图（因为日记帐总是比分类帐保留更多的信息）
将日记帐保留在单独的表中，然后将日记帐分录过帐到分类帐表，从而复制数据
当涉及子分类帐/日记帐时，有些实现将所有信息都存储在一个日记帐/分类账表中，然后使用会计科目表作为基础的不同子日记帐/分类账的不同视图
我已经看到人们为每个子期刊/分类账都有专门的表格，导致表格的数量与特殊日记帐类型（应收账款，应付账款，购买，销售等）一样多。
目前，我的想法是，最多只应该有一个日记帐和一个分类帐表，然后在查询时将通过会计科目表中的定义来编译专门的日记帐/分类帐。我什至可能考虑只使用Journal表，然后在查询时将分类帐作为Joirnals的子集进行编译。
我想检查一下我是否缺少什么？是否有单独的日记帐和分类帐表的真正原因，特别是是否有专门的日记帐>专门的分类帐>普通日记帐>普通分类帐表的原因，因为似乎很多数据重复，插入，更新，删除异常为什么我现在看不到？
最佳答案
主要原因可能是查询SLA。
从我的POV中，我更喜欢使用Journal实体中的所有条目制作3NF数据模型。
然后将日记帐链接到Ledger，COA等。
这样，您就可以使用视图构建分类帐：在3NF模型上，您需要构建一个使用视图构成的语义模型（对于具有紧密SLA的查询，可以是物化视图）。
这样，您可以减少仅使关键查询成为现实的重复，并且可以与其他数据进行将来的集成/分析。