W przypadku pojedynczej, małej, prostej witryny umieściłbym po prostu konfigurację w pliku PHP. Nie komplikuj. PHP prawdopodobnie nie parsuje niczego szybciej niż parsuje PHP. Jeśli używasz APC, skompilowany kod bajtowy jest nawet buforowany — chociaż kod bajtowy jest następnie ponownie wykonywany dla każdego żądania. W przypadku małego pliku konfiguracyjnego wykonanie tego kodu bajtowego powinno zająć bardzo mało czasu; w przypadku bardzo dużego pliku może to zająć trochę więcej czasu.
W przypadku witryn o dużym natężeniu ruchu z dużymi konfiguracjami, dobrym pomysłem jest buforowanie danych konfiguracyjnych w APC (np. jako pojedyncza tablica) — przynajmniej oszczędzasz koszty rzeczywistego wykonywania oświadczenia w pliku config.php. W szczególności Facebook to robi. Kiedy obsługujesz wiele żądań na sekundę, uderzenie dysku w celu odczytania pliku konfiguracyjnego (przy użyciu parse_ini_file, parsera XML itp.) przy każdym żądaniu nie wchodzi w rachubę.
W moim obecnym projekcie hostujemy wiele witryn, każda z własną konfiguracją. Każda witryna miała zarówno bazę danych, jak i plik konfiguracyjny; jednak upewnienie się, że zawsze używasz właściwego pliku konfiguracyjnego z odpowiednią bazą danych, może przysporzyć bólu głowy. Dodatkowo zmiany wymagałyby zmiany rzeczy w dwóch miejscach — w db i config. Zapomnienie jednego lub drugiego zawsze powodowało problemy i zdarzało się to zbyt często.
Przenieśliśmy konfigurację do bazy danych, więc nie można oddzielić bazy danych od jej poprawnej konfiguracji, a wszelkie zmiany w kodzie wymagają jedynie aktualizacji bazy danych. Dane z tabeli konfiguracyjnej są również agresywnie buforowane w APC, więc rzadko o nie pytamy.
Podsumowując:
- Mała witryna :po prostu użyj pliku config.php
- Bardzo duża witryna :pamięć podręczna w APC
- Wiele witryn :przechowuj konfigurację w bazie danych, aby zmniejszyć obciążenie administracyjne; pamięć podręczna w APC w celu zmniejszenia liczby trafień w bazie danych
