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

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

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

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

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

Answer 2

这取决于所使用的会计实务——公司（因为交易方法和他们开始交易的时间）、国家（立法规定该实体必须存在多长时间以及如何对待年终）、业务类型（远期交易（出售或退货商品），交易回线（直接购买/制作的商品，没有贷款、跨账本和金融工具等财务权重），还取决于数据库结构系统及其频率交易被应用到基础 - 查看自上次应用恢复以来已经构建了多少 [非财务 IT] 期刊，并相应地运行“恢复截断”。

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

这个截断的作用不是删除数据，而是清除没有引用回“基础”但系统尚未识别为漏洞的漏洞。 实际上，您已经备份了空间。

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