應該將核心應用程序配置存儲在數據庫中，如果有的話應該採取什麼措施來保護它們？

Question

我正在圍繞很多分層數據編寫應用程序。目前，層次結構是固定的，但未來可能會將新項目添加到層次結構中。 （請讓他們離開）

我目前的應用程序和數據庫設計是相當通用的，沒有任何處理層次結構中的特定節點的硬編碼，除了驗證和查找函數寫入從每個節點的特定數據庫檢索外部數據。從設計的角度來看，這讓我感到滿意，但我很緊張地認識到整個應用程序依賴於數據庫中的一些記錄。我也很沮喪，我必須用數據庫觸發器而不是外鍵約束強制執行數據完整性的某些方面（例如，層次結構中的幾個不同節點都有自己的專有ID，並將它們存儲在單個列中，當加上節點ID可以用來定位外部數據）。

我開始懷疑將這些已知節點簡單硬編碼到系統中是否合適，以便它更「安全」並且通用性更低。

如何知道什麼時候應該硬編碼，什麼時候應該是配置項？這是否僅僅是對清晰度/安全性的成本效益分析，而不是稍後的工作量較少，還是我缺少一些我應該用來確定這是否合適的指標。

我正在採取的保護這些有價值配置的步驟是添加防止更新/刪除的觸發器。此應用程序使用的數據庫用戶只能通過存儲過程操作數據。我還可以做些什麼？

Answer 1

你是在正確的軌道上。有一點成本效益。其他考慮因素是維護和複雜性。

複雜性：任何動態層次結構都將比靜態層次結構更復雜。這涉及更多的編碼和測試，因爲還有更多可能的失敗案例。如果您目前沒有需要更新層次結構，那麼複雜性可能不值得嗎？我們經常過度優化複雜性，因爲我們預計未來會發生變化。這導致我進行維護...

維護：考慮您的層次結構變化的用例。什麼樣的外部事件會引發需要維護層次結構和誰來確保發生這種情況？這種改變是否需要備份，審計，版本控制，批准，上演等？源代碼管理系統提供了許多這些功能。因此，例如，如果層次結構代表公司的業務單位，並且您的用例是未來的公司合併，那麼假設HR系統中的靜態層次結構可以通過以下方式進行更新將是非常合理的：程序員。事實上，在合併中，整個系統可能會被拋出（！）。另一方面，如果層次結構是產品目錄，我們都知道市場營銷人員會定期對這些數據進行重新規劃和細化。此外，如果他們被告知將有一個爲期兩週的軟件項目來重新編碼，測試和重新部署每個季度的目錄，我很確定他們不會對設計感到滿意。因此，動態的DB驅動模型是有意義的。