会计数据库设计问题“账户”和“交易”
选项 1）用户可以拥有多个“帐户”（例如付款、存款、取款等）
选项 2）用户只能有 1 个帐户，并且交易有类型（付款、存款、取款）
这两个选项都可以正常工作！他们都可以产生相同的结果！然而选项1使用更多的资源，但它更灵活，选项1不灵活但使用更少的资源！
Option 1) user can have multiple "accounts" (eg payment, deposits, withdraws etc)
Option 2) user can only 1 single account, and transaction has types (payment, deposit, withdraw)
Both option will work just fine! They both can produce the same result! However option 1 uses more resources, but it's more flexible, option 1 is not flexible but uses less resources!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
问题是什么？
选项1是垃圾，会计师无法使用，审计师也无法通过。付款、存款、取款等交易，而不是“账户”。如果它使用更少的资源又怎么样呢？穴居人也是如此。
选项 2 开始看起来像一个会计系统，如大多数发达国家所预期的那样，具有 (a) 账户和 (b) 账户交易。
所以别无选择。
What is the question ?
Option 1 is a piece of garbage, that no accountant can use, and no auditor will pass. payment, deposits, withdraws eta re transactions, not "accounts". So what if it uses less resources. SO do cave men.
Option 2 starts to look like an accounting system, with (a) accounts and (b) transactions against accounts, as expected in most developed countries.
So there is no choice.
从链接到会计科目表的日记帐表开始。在日记帐表中，您将存储交易日期、帐户代码、描述、金额等字段名称。科目表表是您存储字段名称的位置，例如帐户代码、帐户类型（资产负债表或损益表）、帐户状态（活动或非活动）。有关会计数据库架构的更多详细信息，请下载 derek Liew 的有关会计数据库设计的书。
Start from a journal table, that link to a chart of accounts table. In your journal table is where you will store fieldnames for transaction date, account code, description, amount. chart of account table is where you will store fieldnames like account code, account type (balance sheet or profit and loss),account status (active or inactive). For greater details on the accounting database schema, download derek liew's book on accounting database design.