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 ...）中，如果是的，如果使用了錯誤的報告期刊代碼，那將是一場噩夢。