Settings
Posted: Thu Nov 24, 2005 3:14 pm
Where do you store settings of your applications - file or database? Of course, I want to allow users to edit those via web interface.
A community of PHP developers offering assistance, advice, discussion, and friendship.
http://forums.devnetwork.net/
I typically like to avoid this situation as much as possible, since variables that appear out of nowhere lean towards bugs (atleast in my personal experience) I prefer to use a config table in a database at the expense of a slight overhead which can be called at any time throughout my application through a configuration controller class of some type. This lets me know exactly where my variables are coming from.pickle wrote:Most (read: all) of my applications are one-offs that only I deal with. That said, I almost always put configuration variables in a config file. I think there's slightly less over head because to retrieve them from the DB, I need to do a query, parse the results and store them in variables. By storing the variables in a file, the variables are declared whenever that file is included.
If you want the variables to be editable by a user though - it'll be much easier to pull and store in a database rather than a file.
Of course at some point your going to have to hard code some creditials, and as mentioned before I like to minimize the amount of data stored in files (fyi. these usually should be outside the webroot) so in most of my applications I have left this file strictly for database credentials -- whatever else that needs to be configurable may be done so through the database.Ambush Commander wrote:It depends. For instance, database credentials can't be stored in a database (big surprise...)
So here's what I do: make a local_settings.php that takes a Plugin object and sets lots of configurations (db login, fairly static config options)
Something I did recently, in order to avoid that sort of thing. I'll probably decide it wasn't ideal later.Jcart wrote:I typically like to avoid this situation as much as possible, since variables that appear out of nowhere lean towards bugs (atleast in my personal experience) I prefer to use a config table in a database at the expense of a slight overhead which can be called at any time throughout my application through a configuration controller class of some type. This lets me know exactly where my variables are coming from.
Code: Select all
class settings
{
const DBServer = 'localhost';
const DBUser = 'username';
const DBPass = 'password';
const DBName = 'whatever';
const showIcons = 1;
//etc etc
}Code: Select all
class DB extends settings
{
private $DBConn;
function __construct()
{
//Conect to database yadda yadda
}
}
class core extends DB
{
//and the structure goes on
}Code: Select all
class SomeClass
{
function SomeClass ()
{
// legacy constructor
$this->Config(); // auto-load class config
$this->CheckConfig(); // Check that the config is valid
// CheckConfig is useful in case a number of options are available to select and
// you need to verify that an option is of an allowed string (eg HIGH | MED | LOW)
}
function Config ()
{
define ("ConfigValue", "value"); // define a class configuration variable
}
function CheckConfig ()
{
if (!is_string(ConfigValue))
{
// my class actually calls an error class but...
print "Unexpected variable type";
exit;
}
}
}For my game, I wanted virtually every variable to be real-time editable (is that even a word?!?!).Ree wrote:Where do you store settings of your applications - file or database? Of course, I want to allow users to edit those via web interface.
Reload it from the ini file.BDKR wrote:Settings that are key or critical to the app should be stored in a file as far as I'm concerned. Otherwise, what do you do when the DB takes one in the gut?
Code: Select all
SELECT `key`, `value` FROM `configuration`I disagree that is a recipe for disaster. I have never had any performance issues before.. perhaps your idea of this design is flawed.Ambush Commander wrote:Since trying to lazy load configuration variables would be a recipe for disaster, or at least, really slow applications.Code: Select all
SELECT `key`, `value` FROM `configuration`