配置文件vs數據庫表

我特別感興趣的場景是多臺服務器具有在某些配置參數上運行的守護進程。（因爲這是一個學習練習，我歡迎超出這個特殊情況的任何想法）問題是，配置參數應該放在哪裏。配置文件vs數據庫表

A.中央數據庫表

B.一個配置文件推送到每個框

這是最常見的，我碰到過。其他值得注意的是，在代碼常量中（需要重新編譯才能部署，除非它們真的是常量，否則選擇這麼糟糕的選項），將配置文件安裝在共享位置上。

只是想從社區知道你如何去做選擇。

來源

2010-07-06 neal aise

這一切都取決於您所管理的操作規模。

如果位置數量很大和/或更改頻繁，請使用數據庫。

否則，請使用配置文件。

如果對集中式數據庫的訪問速度太慢或無法接受是故障點，但規模仍然很大，請使用像Puppet這樣的自動化系統。

來源

2010-07-06 22:34:44 Borealid

最後一點可以通過從站和查詢緩存來緩解。 – 2010-07-10 09:37:33

如果可能，我的首選是數據庫。我願意在應用程序啓動時支付性能成本。保存數據庫的選項比配置文件更多。 – Vadim 2011-10-22 14:12:21

大多數需要在服務器/應用程序之間共享配置參數的公司最終創建了自己的配置機制，並將它們存儲在家庭關係數據庫中。我認爲規模並不重要。必須登錄到多臺服務器才能檢查文件系統上的配置是一場噩夢。但是，即使在中央數據庫中管理配置時，您仍然必須確保配置易於訪問。我已經看到這種類型的配置在3家不同的公司使用，而且它是以真正成功的方式使用的唯一地方，就是應用程序公開了一個簡單的用戶界面，允許系統管理員調整設置。如果只能通過使用SQL客戶端訪問，那麼您會發現配置很容易「丟失」或者更糟糕，重複。

上面的海報提到了Puppet，我從來沒有用過，但它看起來很有趣。但它看起來並不像它支持Windows [1]：http://www.puppetlabs.com/puppet/requirements/

來源

2010-07-06 22:45:40 warriorpostman

同意具有用於訪問參數的用戶界面/或至少一個API。它限制了你獲取/設置配置參數的方式，當然也允許你在配置文件和db表之間切換回來:) – 2010-07-10 09:40:31

如果配置屬性可以在運行時更新，集中在數據庫中的屬性將使生活更輕鬆。

來源

2010-07-06 23:25:01 btreat

配置文件vs數據庫表

回答

相關問題