是否應將當前應用程序狀態存儲在數據庫中？

Question

我已經開始研究一個項目，其中Postgres數據庫被用作系統架構中的一個組成部分。這迫使我放棄以前的觀點，即數據庫很好，存儲事物。

有一個API將傳入的請求轉換爲數據庫查詢/更新。這會導致數據庫中的觸發器通知其他應用程序相應地更新實際系統。

對我來說，這一切似乎沒有必要。這也是一個相當系統關鍵的體系結構，但我們無法保證底層系統故障的知識使其備份鏈，因爲一切都是異步。總之我不喜歡它。我的觀點是，我們應該立即重新啓動，使用API​​和底層系統之間的直接通信，使用數據庫來存儲持久狀態更新/用戶信息等。

我真的在這裏尋找的是有人解釋對我來說，爲什麼我錯了，然後我最終與團隊脫口而出，但所有的觀點都是值得歡迎的。

Answer 1

的唯一理由支持這樣的整合是其成本低，特別是如果兩個集成系統利用自身的技術proprietry壞comminucating彼此。另外，DB集成呈現舊式集成。

要acheive（或者至少增加）所謂的「自主性」。談論這個話題太大了，但我會根據你的情況試着突出最重要的東西。

1. 觸發器和存儲過程幾乎總是邪惡的。它總是會導致DB的「邏輯泄漏」，從而導致業務邏輯和整個應用程序的可移植性和可維護性差。存儲過程唯一可能是有用的是提高性能。但是沒有它們，有很多方法可以調整績效。
2. 只要你的應用程序通過DB連接你正在處理他們之間的緊耦合，因此它們緊緊地依賴於這兩個應用程序的對方，因此可維護性和可重用性受到影響。
3. 通過以某種複雜方式通過數據庫連接應用程序，您可能還會在未來遇到擴展問題。
4. 使用DB解決方案來調用您正在處理的與技術耦合的事情，而這種解決方案並非設計用於實現這一點。因此缺乏靈活性和未來可能的侷限性。如果使用一些非標準化的專有工具和協議，它會更糟糕。

今天（企業）的最佳做法是使用與應用（未集成）非共享的數據庫完全獨立的應用程序，通過標準的協議進行通信，可能是通過一些可靠的中間件。它比較昂貴，但它提供了很多好處（可伸縮性，可維護性，靈活性等）。

要決定你是否應該重寫某些東西，首先你需要估計成本和收益。如果它是一個很好的傳統緊密耦合的組合，它可以很好地工作，可能不是最好的方式來觸摸它，但如果需要的話，創建類似Facade的包裝。

最後，

我真正想找這裏是有人向我解釋爲什麼我 錯

我不認爲你錯了。