在数据库中存储（子）期刊和（子）分类帐以用于会计应用程序答案

【问题标题】：Storing (Sub)Journals and (Sub)Ledgers in DB for accounting app在数据库中存储（子）期刊和（子）分类帐以用于会计应用程序
【发布时间】：2016-12-29 05:23:13
【问题描述】：

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

仅保留日记信息，然后分类帐只是日记的视图（因为日记总是比分类帐保留更多信息）
将日记帐保存在单独的表中，然后将日记帐分录到分类帐表中，从而重复数据
当涉及到子分类帐/日记帐时，有些实现将所有信息都放在一个日记帐/分类帐表中，然后使用会计科目表为不同子日记帐/分类帐提供不同的视图
李>
我看到人们为每个子期刊/分类帐都有专门的表格，这导致有与特殊期刊类型（应收账款、应付账款、采购、销售等）一样多的表格。

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

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

【问题讨论】：

标签： database-design accounting

【解决方案1】：

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

通过这种方式，您可以减少仅实现关键查询的重复，并且您可以在未来与其他数据进行集成/分析。

【讨论】：

感谢您的回答。让我澄清一下：在一个地方你说日记帐与分类帐相关联（听起来分类帐是单独的表格），而在另一个地方你说分类帐是用视图构建的（听起来没有分类帐表）。你能确认一下是什么情况吗？谢谢
所有条目都在日记帐中，并且实体“ledger”仅包含与特定分类帐相关的少数属性（或者如果需要，还可以从日记帐中提取汇总值）。要提取分类帐条目，您必须将模型从分类帐导航到日记帐。
但最重要的是，您更喜欢 Ledger 作为一个视图（在日志上）而不是单独的表？
是的，完全正确。这可以保持规范化，您可以使用某种优化（索引、分区等）来有效地检索特定分类帐的条目。
hm...我不确定为什么您的答案没有获得赏金。一个选项消失了。