單個數據庫VS多個數據庫ERP會計年度交易表？

主要問題：
我們有客戶，也許每年收入超過2個米利翁交易雙輸入系統/ AKA（日刊）的所以每年所有的交易將張貼到明年年初餘額爲單行爲每個帳戶。沒有發佈去年的任何期刊。所以我的意思是每年都清楚地使用空的Transaction Journal數據庫。
所以，我們需要了解第二種方法（單個數據庫的所有年份）例如添加欄要求Period_Year

單個數據庫VS多個數據庫ERP會計年度交易表？

可以去看兩種途徑這裏：
1 - 多個數據庫每年交易
2-單個數據庫的所有交易通過添加Period_Year列

問題我集中在第一個方法（多數據庫）：
1-許多數據庫如果客戶擁有10年會計期間
2 - 如果舊年數據庫修改它必須張貼到新年數據庫。
3-如果客戶端在線託管，那麼通過託管服務提供商限制數據庫數量
4-如果客戶需要報告（2016 - 2018年），交叉查詢可能會出現問題。

問題我集中在第二方法（單個數據庫）：
1-非常巨大的數據庫大小。使我們的技術支持需要時間備份&維護
2-如果技術支持更新沒有使用目標的期刊憑證Period_Year
它可能會破壞所有會計年度！
3-在UI/GUI層緩慢加載。
4-報告慢慢也。

我知道第二個方法，如果採用指數>>也許將是巨大的..

*所以，請告訴我哪些是很好的解決方案爲：*

- 易於維護
- 高性能
- 數據庫大小
-Cross查詢
-GUI/UI響應
- 靈活的搜索& CRUD SQL（UPDATE，INSERT，DELETE）
-Reports &儀表盤

所以哪一個是好辦法？單個或多個數據庫？

問題已完全修改。請任何人集中相同的問題或需要給我一些建議/技巧將不勝感激謝謝。

來源

2017-07-02 user3717917

您在第二種方法中列出的問題是組成問題。它們表示某些其他*錯誤，而不是您指示的表格大小。你的第一種方法只是爲了掩蓋這些問題並將其替換爲其他問題，但實際上並沒有解決這些問題。 – David

問題和解決方案的哪些部分是C＃沒有數據庫設計？ –

是嗎？什麼是好的解決方案？建立檔案數據庫？或第一種方法？或第二種方法或什麼.. – user3717917

您的問題涉及所謂的分區問題，您可能需要採取幾種方法調查不同的策略以滿足您自己的特定需求。根據我的經驗，在類似的情況下處理類似數量的交易爲一些客戶提供更多的交易，因爲沒有必要實施分區，因爲所有解決方案都會增加不必要的成本和複雜性。相反，所需要的只是實施索引和維護計劃。

作爲替代方案，您描述的分區方法可以使用SQL Server按年分區單個表的事務數據和索引，但該解決方案可能會很昂貴，因爲它需要Enterprise SQL。

考慮到你正在考慮的兩種解決方案，將你的表分成多個表不會減小數據庫的大小。它至少會有相同的大小，因爲如果你的單個表包含1 GB的數據拆分爲兩個，這意味着你將創建兩個表，每個數據庫各有1.5 GB，但數據庫仍將爲1 GB。事實上，它可能會使數據庫變大，因爲您需要在將用於將表連接在一起的列上創建附加索引。您還需要更復雜的邏輯才能跨多年查詢和更新數據。

單表方法很可能是最好的方法。這將是最容易維護和發展的，並且具有最低的總體成本。使用數據庫的正確索引和維護計劃可以實現高性能和GUI響應。沒有必要交叉查詢表格。

來源

2017-07-02 19:30:20

嗯是的，也許你是真實的和答案是好的，但ihate插入新的列名爲附加當前的主鍵，所以如果我有交易文件包含這些列：分支，類型，數量這些3複合鍵必須添加年份列以使交易可以獲得新的數字，但是對於目標年:(對於此的任何替代方案？ – user3717917

我不確定您的特定需求是什麼。根據我的經驗，每當我們處理財務或會計目的的交易時如果不是完整的日期和時間，則至少有一個日期列。您從不希望處於需要更新或刪除特定時間段內的交易（可能是由於審計或發現欺詐）的情況，並且您可以事實上，幾乎每個我創建的表，交易或其他表，都至少有最後修改日期，如果不是創建和最後修改的日期，則用於審計目的秒。 –

你是否知道SAP/Oracle如何做到這一點......我真的無法搜索，但如果你有很好的方法併爲我提供實時的想法將會很棒。謝謝。 – user3717917

這取決於公司使用的會計慣例（由於交易方式以及何時開始交易），該國的法律規定聲明該實體必須存在多長時間，以及年終時間（交易遠期（貨物出售或退貨），交易回購（完全沒有財務重量的貨物，如貸款，轉賬分類賬和金融工具），這也取決於數據庫結構體系以及其交易應用到基地的頻率 - 查看自上次應用恢復以來已建立了多少[非金融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 ...），所以很好，如果如果使用了錯誤的報告日記代碼，這是一場噩夢。

來源

2017-07-03 09:45:23 Steve

單個數據庫VS多個數據庫ERP會計年度交易表？

回答

相關問題