主要问题：
我们的客户可能每年都会进行超过2百万的双重进入系统交易/ AKA （每日期刊）
因此，每年所有交易都将发布到明年作为每个账户的单一行的期初余额。没有发布上一年的任何期刊。
所以我的意思是每年从空的交易日志数据库开始。
所以我们需要了解第二种方法（全年单一数据库）
例如，添加名为 Period_Year 的列
这里有两种方法：
1-每年交易的多个数据库
2-添加Period_Year列的所有交易的单一数据库
我在第一种方法（多数据库）中聚焦的问题：
1-许多数据库如果客户有10年会计期间
2-如果旧年数据库修改它必须发布到新的数据库。
3-如果客户端在线托管，则由托管服务提供商限制数据库数量
如果客户需要报告（2016 - 2018）年，那么交叉查询可能会出现问题。
问题我专注于第二种方法（单一数据库）：
1-非常非常大的数据库大小。让我们的技术支持需要时间备份＆amp;维护
2-如果技术支持更新日记帐凭证而不使用目标期间_年11，它可能会破坏所有会计年度!!
3-在UI / GUI层中慢速加载。
4-报告也很慢。
我知道第二种方法如果使用索引＆gt;＆gt; ..
，也许会很棒
*请告知我哪个是好的解决方案：*
- 易于维护
- 高性能
- 数据库大小
-Cross查询
-GUI / UI响应
- 灵活搜索＆amp; CRUD SQL（更新，插入，删除）
- 报告＆amp;仪表板
那么哪种方法很好？ 单个或多个数据库？
问题已完全修改。请任何人关注同样的问题或需要给我 一些建议/提示将不胜感激。
答案 0 :(得分：0)
您质疑所谓的分区问题，您可以采取多种方法来调查满足您自己特定需求的不同策略。根据我的经验，处理类似情况并为一些客户提供更多交易的类似事务，没有必要实施分区，因为所有解决方案都增加了不必要的成本和复杂性。相反，所需要的只是实现索引和维护计划。
作为替代方法，您描述的分区方法可以使用SQL Server按年划分单个表的事务数据和索引，但解决方案可能很昂贵，因为它需要Enterprise SQL。
考虑两种解决方案，将表拆分为多个表不会使数据库大小变小。它至少会是相同的大小，因为如果你的单个表包含1 GB的数据分成两个将意味着你有两个表.5 GB，但你的数据库仍然是1GB。事实上，它可能会使您的数据库变大，因为您需要在用于将表连接在一起的列上创建其他索引。您还需要更复杂的逻辑来跨多年查询和更新数据。
单表方法很可能是最好的方法。它将是最容易维护和开发的，并且总体成本最低。通过数据库上的正确索引和维护计划，可以实现高性能和GUI响应。无需交叉查询表。
答案 1 :(得分：0)
这取决于所使用的会计惯例 - 公司（由于交易方法和何时开始交易），国家（经合法规定该实体必须存在多长时间，以及如何处理年终） ），业务类型（交易（销售或退货），交易（直接购买/制造，没有金融重量的货物，如贷款，转账和金融工具），它还取决于数据库结构系统和它的交易应用于基数的频率 - 看看自上次应用恢复以来已经建立了多少[非金融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 ...）所以很好对，如果使用了错误的报告期刊代码，那就是一场噩梦。