アプリケーション全体の「設定テーブル」は良いアイデアですか？

Question

たとえば、Wordpressには、アプリケーション全体の設定（ブログの名前、コメント設定など）を格納するために、name => value行のテーブルがあります。私は、アプリケーションの通常の使用中に頻繁に変更される可能性のある設定を指していることに注意してください。

私はWordpressがそういったことを理解しています（移植性：データベース全体を別のブログにコピーして設定を保存するのは簡単ですが）小規模なアプリケーションではより良い方法がありますか？

たとえば、Zend Frameworkのような多くのフレームワークには、アプリケーション全体の構成設定を含む構成ファイルがあることは知っています。ランタイムにそのファイルを動的に変更して設定を保存しないのはなぜですか？

• 少ないデータベースを使用
• 設定
• 設定ファイルを簡単にバックアップすることができますMySQLのシェルを必要とせずに簡単に人間が編集可能なFTP経由であるか、phpMyAdminのインスタンス：私にとって、これはデータベースの設定の保存に比べていくつかの利点を持っています復元されました

一方、私が考えることのできる最大の複雑さは並行性です。変更が行われている間、ファイルをロックする必要があります。

どのような方法が好ましいですか？

Answer 1

DBテーブルの利点

• 設定は同じデータベースを共有するすべてのWebサーバーに対してグローバルです。アプリケーションは、ほとんどの場合、すでにデータベース、余分なセットアップファイルシステム上の
• なし目的
• キャッシュすることが容易に（おそらくいくつかの一般的なDBのキャッシュ層がすでに存在しているのですか？）
を使用するファイルの複製/ネットワーク・ファイル・システム
• の必要ありません
• は、アプリケーションがすでにあなたのアプリケーションの残りの部分
• とフレームワークまたは任意のデータベーステーブルのCRUDを処理する方法（GUIを作成することは簡単です）
• 透明なバックアップがあることができますがあり、同時実行
• を処理しますあなたが排他的に

使用される様々なタイプのいくつかのvalue列を持っている...そして、あなたはそれを

を維持するためのツールやSQLの知識を必要とする欠点

• がが悪化した性能を持っている可能性がある場合は、強く型付けされました