复式记帐模式

Question

设置复式记账系统供个人使用并帮助管理真正的小型企业。尝试添加一些现在看起来相关的功能。

商业规则

对于不熟悉会计的人来说，其逻辑是：货币不会被创造也不会被销毁，它只是从一个账户转移到另一个账户。每笔交易都有借方和贷方。几个例子：

1. 雇主的薪水：贷记Salary、借记Bank Account- 钱来自您的薪水，并存入您的银行帐户。

2. 支付租金：贷记Bank Account、借记Rent- 钱来自您的银行帐户并转到您的租金帐户。

账户可以是“股票”账户，即账户余额是累计的（银行账户就是一个很好的例子），也可以是流量/流量账户，即账户余额是非累计的（租金是一个很好的例子）。

设计背后的逻辑

这个想法是有一个JournalDB存储主要条目的主表。该表JournalTx存储了交易中涉及的每个帐户。每个条目 (from JournalDB) 都有一个 ID，并且每个事务 (from JournalTx) 都链接到一个日记帐条目。基本情况是 中有 1 个条目JournalDB和两个（或更多）事务JournalTx。每个条目都可以有 a cost_center、 aproject和一些其他属性。

基本上有两种设计方式（根据这个问题） - 每个事务样式一行，每个事务两行。在第一个中，我将有一个信用帐户和借记帐户的行，在第二个（这个）中有 n 行，每个受影响的帐户一个。

帐户

Accounts 表是会计科目表（用会计术语）。它具有层次结构 - 我使用了邻接列表样式。虽然不是很频繁，但账户会有 CRUD 操作。我补充说parent_imediate，parent_second作为一个非常丑陋的聚合解决方案（例如，计算资产账户的总数），但考虑到挑战（经过长时间的研究，不知道如何做到这一点），这似乎是一个简单的出路 -也欢迎就此事项提出任何意见或建议。

主要查询

获取报告，通常是 montlhy：基本上所有帐户都包含影响每个事件的聚合交易。最好的情况是数据透视表（列作为日期），每一行都是一个帐户。我想这个的“堆叠”版本也可以正常工作。

帐户只是一个维度 - 例如，我可能想要查询 bycost_center或 by project。

其他特性

我想有能力预算帐户（因此预算表），以及有“目标”（我想休假，这将花费我 1.000 美元）。我也想要标签，并且能够设置经常性账单（这是“预期”交易）

基本关系

一个条目 (journal_db) 有许多事务 (journal_tx)。一个cost_center、project等有很多条目一个账户有很多交易。一个联系人有多个条目。

我的主要疑问

我刚刚开始学习数据库/编程，所以请容忍我的明显错误。

1. 从编程/性能/功能的角度来看，这种设计是否可靠？
2. 如何实施报告？查询数据库（派生表）或创建新表（如 journal_reports），并创建触发器以更新每个条目的帐户余额？（在这个问题中阅读这不是一个好主意）
3. 有什么我可能会遗漏的吗？

Answer 1

我认为你的问题非常广泛，很难完整回答。但我注意到您的设计有以下几点：

总体设计

您设计中的某些表违反了第一范式。一个很好的例子是contact_adress其中有adress1,adress2和adress3作为列。通常一个地方只有一个街道地址，然后一个地址列就足够了，但如果您确实希望能够将多个街道地址添加到一个地方，则应该将这些地址移动到另一个表（ , contact_adress）street_adress。journal_bills对于( detail1, detail2) 和表也是如此accounts：而不是parent_imediate,parent_second和parent_third单个parent属性就足够了。要获取第二个或第三个父级，您可以使用递归 CTE。

我不知道您所有的业务需求，但您应该检查您的设计是否允许您输入无意义的数据：帐户可以同时是现金和信用卡吗？如果有货币，汇率是多少？邮政编码可以以一个或多个零开头吗？电话号码怎么样？对于某些事情，有最佳实践，例如如何处理重复发生的事件。

命名

有些列名很难理解（ag、acc、pmt），如果其他人必须使用您的数据库，这可能会导致可维护性问题。使用风格指南如果您不确定如何命名事物，一般来说，坚持一致的命名方案是个好主意，例如为每个表指定一个复数名称。

如何落实举报？

我会坚持使用简单的 SQL 查询，并尝试远离触发器等复杂的函数，除非确实需要，但对于简单的应用程序来说可能永远不会出现这种情况。