ERP会计年度交易表的单数据库VS多数据库？

Question

主要问题：
我们的客户可能每年进行超过 200 万笔复式录入系统/AKA 交易（日报） 所以每年所有交易都将作为每个账户的单行的期初余额发布到明年。没有发布上一年的任何期刊。 所以我的意思是每年都从空的事务日志数据库开始。
所以我们需要了解第二种方法（所有年份的单一数据库） 例如添加名为 Period_Year 的列

这里有两种方法：
1- 每年交易的多个数据库
2- 添加 Period_Year 列的所有事务的单个数据库

我在第一种方法（多数据库）中关注的问题：
1- 如果客户的会计期为 10 年，则许多数据库
2- 如果旧年数据库被修改，它必须发布到新年数据库。
3- 如果客户端在线托管，则托管提供商会限制数据库数量
4- 如果客户需要（2016 - 2018）年的报告，交叉查询可能会出现问题。

我在第二种方法（单一数据库）中关注的问题：
1-非常非常大的数据库大小。让我们的技术支持花时间进行备份和维护
2- 如果技术支持在不使用目标 Period_Year 的情况下更新日记帐凭证
它可能会破坏所有会计年度！！
3- UI/GUI 层加载缓慢。
4- 报告也很慢。

我知道第二种方法如果使用索引可能会很棒>>..

*所以请告诉我哪些是好的解决方案：*

-易于维护
-高性能
-数据库大小
-交叉查询
-GUI/UI 响应
-灵活的搜索和 CRUD SQL（更新、插入、删除）
-报告和仪表板

那么哪一个是好方法？ 单数据库还是多数据库？

问题已完全修改。请任何人关注同样的问题或需要给我 一些建议/提示将不胜感激。

Answer 1

这取决于所使用的会计惯例 - 公司（因为交易方法和开始交易的时间）、国家/地区（立法规定该实体必须存在多长时间以及如何处理年终)，业务类型（远期交易（出售或退货的货物）、交易回程（直接购买/制造的货物，没有财务权重，如贷款、跨账本和金融工具）），它还取决于数据库结构系统和它的事务多久应用到基础 - 查看自上次应用还原以来已构建了多少 [非金融 IT] 期刊，并相应地运行“还原截断”。

虽然“小”这些日志可以膨胀并创建一个巨大的备份 - 一个 280Mb 的数据库在一夜之间变成了 3.8Gb，因为没有人“截断”并应用他们生成的事务日志 - 但它可以长时间运行并且不能被中断一旦触发 - 恢复需要 75 分钟，然后再次变为 280Mb！这方面的日志与 IT 相关，是系统记录要应用于“基础”的更改的方式。最多应该有一个低数字，更多，系统的速度和大小会降低。如何做到这一点取决于数据库 - 作为示例here https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=GCDI_backup_restore_jrnaftbackup 。

此截断的作用不是将数据切掉，而是清除没有参考回“基础”但系统尚未识别为孔的孔。实际上，您已经备份了空间。

至于前滚日志 - 它取决于日志的使用及其内容 - 如果为零，那么当日志前滚时，包含的交易余额不是。查找前一两年没有交易的 0 余额日记帐。公司喜欢为特定项目使用生成报告财务日记帐 - 但在该项目完成后继续存在，但为空。其他人创造了一个“面具”。覆盖交易的日志报告系统完全是另一个方面 - 我工作的一个系统将日志掩码扩展到 38 个（即 38 个！级别 38x37x36x35x34x33x32x31 ...）在集合组（7,5,12 ...）中，如果对，如果使用了错误的报告日志代码，那将是一场噩梦。

Answer 2

您的问题涉及所谓的分区，您可以采取多种方法，您必须研究不同的策略以满足您自己的特定需求。以我的经验，在处理类似情况的情况下，某些客户的交易数量相似，交易数量更多，没有必要实施分区，因为所有解决方案都增加了不必要的成本和复杂性。相反，所需要的只是实施索引和维护计划。

作为替代方案，您描述的分区方法可以使用 SQL Server 按年对单个表的事务数据和索引进行分区，但该解决方案可能很昂贵，因为它需要 Enterprise SQL。

采用您正在考虑的两种解决方案，将表拆分为多个表不会使数据库大小变小。它至少是相同的大小，因为如果您的单个表包含 1 GB 的数据分成两个，则意味着您有两个表，每个表 0.5 GB，但您的数据库仍然是 1 GB。事实上，它可能会使您的数据库更大，因为您需要在用于将表连接在一起的列上创建额外的索引。您还需要更复杂的逻辑来查询和更新多年的数​​据。

单表方法很可能是最好的方法。它将是最容易维护和开发的，并且总体成本最低。使用正确的数据库索引和维护计划可以实现高性能和 GUI 响应能力。无需交叉查询表。