パブリックWebアプリケーションが構成にiniファイルを使用しないのはなぜですか

そこにあるほとんどすべてのパブリックCMSは、データベース設定などに.php構成ファイルを使用しています。たとえば、WordPressをインストールすると、.php設定ファイルが自動的に作成されます。

なぜ.iniファイルを使用しないのですか？PHPには既にparse_ini_file（）があり、他の言語にも同様の関数があると思います。

特にPHPでは、.iniファイルと.conf.phpファイルの違いはごくわずかです。

PHPを構成に直接使用すると、構成用に1つの明確に定義された移植可能な構文に関連付けるだけでよいという明確な利点があり、構成ファイルが適切にコードであるという事実が役立つ場合があります。

それに比べて; iniファイルにはほとんど何もありません。およびinclude、requireそしてrequire_onceすべてがよく知られており、（ほとんど）よく理解されています。

一般的に言えば.ini、XML構成ファイルを使用します。大規模なシステムでは、多くの場合、開発者以外の誰か、おそらくDBAまたはsysadminが構成値を変更する必要があります。私が知っているほとんどのDBAとシステム管理者は、単純なPHPスクリプトをナビゲートするのに何の問題もありませんが、そうでない方がいいと思います。小さな間違いが1つでもあると、アプリケーション全体にかなりの数の害が及ぶ可能性があります。

しかし、小規模なシステムでは、PHPスクリプトを使用して構成するのが非常に便利です。今日はAWS SDKをいじっていましたが、これも構成にPHPスクリプトを使用しています。

CFCredentials::set(array(
    'development' => array(
        'key' => 'xxx',
        'secret' => 'xxxx',
        'default_cache_config' => sys_get_temp_dir(),
        'certificate_authority' => true
    ),
    '@default' => 'development'
));    

をハードコーディングする代わりにdefault_cache_config、システムのtempを渡します。これは、スクリプトを展開するすべてのシステムで機能します。このスクリプトは、10人程度の開発者に渡される小さな概念実証です。私は、何も考えずに、そのまま実行してほしいと思います。プロトタイプが進化した場合、私はそれを私のXML構成クラスにハードワイヤーします（明らかにファイルシステムキャッシュに依存しません）。

答えは簡単です。conf.phpの動作に必要な作業は基本的にゼロです。これは単なる別のソースファイルです。

キャッシュなしの速度も理由になり得ます。PHP設定は、必要に応じて透過的にopcodeキャッシュできます。一方、INIファイルは、読み取られるたびにテキスト解析される必要があり、キャッシュを自分で作成する必要があります。小さなファイルの場合は問題ありませんが、リクエストごとに何百行も解析されるため、200ミリ秒に最適化されたWebの場合、数十ミリ秒に達する可能性があります。