I'm curious myself what the op meant by elegant. In this case I think a flat file wouldn't be elegant because the more settings that are stored in the INI files the more memory and processing power will be used to find specific settings in it (remember the op is already using individual INI files for each user, who knows how many settings are already stored in it).
I think your getting OP confused with me.
Anyways...I really dought that INI files are more demanding on the server than a DB. Yes INI files need to be parsed each request (this is very fast) and the memory...well remember he needs access to these variables at some point so he either fetches them one at a time from the DB (which would be sloooow) or he pulls them into variables/objects anyways, so what difference does it make whether the data originated from a database or INI file?
Having to read the contents of the entire file into memory for a handful of settings to me seems sloppy. Especially when the same could be done with a lot less fuss by, "SELECT setting1,setting2 FROM settings_table WHERE userid = ?". Now you have an result without unnecessary stuff to parse.
Sloppy? Why?
Seems to me, that keeping settings in a INI file (which is what the INI file is intended to do -- RDBMS are designed to store relational data, not configuration data) would make most sense. Considering the application depends on the settings data to initialize itself, if a DB connection failed, your application would just flat out crash. At least if the application can initialize itself, it might have the common sense at that point to display a friendly error and maybe email/notify the admin of a downed database.
Pulling in configuration data using a single SELECT is easy enough, but what happens when a setting gets added or removed? Now you need to update the INSERT/UPDATE queries to reflect the new schema -- PITA.
Why would the schema of the database need to be updated? All you would do is be working on a specific row that correlates with the settings of a specific user
Because if your settings are, for example:
Code: Select all
show_popups, enable_mailing, notify_admin_on_failure, last_selected_tab, etc
Then one day you decide to add a field or remove a field (ie: setting)...you either have ot update the INSERT/UPDATE queries or using phpMyAdmin to add the fields. Manipulating an INI file is much easier.
Also, why would a setting be stored as an image
No idea, I'm not entirely sure what OP is after...whether it's a 1:1 automated storage solution of form data to a data table or whether he's storing application configuration data, like I have shown above.
If he was after a FORM solution that it's possible a user might upload a photo, which would require a BLOB field type and thus no longer work keeping it in the datbase.
Where do you get that the configuration data would be the user/pass/port/name of the database your connecting too; this would be ridiculous to store in a database since you would need those values to retrieve those values.
That was my point exactly. It's important to determine what kind of data he is going to store. Configuration data doesn't really fit well in a database for that reason. Database, SMTP, IMAP, etc...all require authentication, configuration details...much like file paths or whatever. Keeping those details in the database means if the database doesn't work, the application doesn't work. Granted most apps rely heavily on DB's for data storage/retreival but no one system should ever be responsible for catastphoic failure -- every engineering discipline follows that principle, programming should be no different.
Clearly whats being stored is data that will assist in making elements on a page persistent, not db connection info. I think your just nitpicking here and trying to find reasons to justify your stance.
What stance? What nitpicking? Yes I nitpick, thats the point of coming to a forum, uncover every rock, being pedantic.
I'm simply saying that configuration data doesn't belong in a database. While there are instances where it might make sense (such as a supporting multiple application installations with a single physical install) for the most part, I think it's good practice to keep config data out of the database. Perhaps you are just offended because you keep config data in a database table?
Seriously though, I'm not clear on "what" exactly the OP is storing in a table...form "data" is not configuration settings...it's "data" and does belong in the DB.
If he is persisting the users environment, so the application returns to exepcted state on next visit, that is not database data, it's registry data or configuration data.
Windows has the registry which superceeded the INI file but the principle is the same.
Ultimately the choice is the OP's whether he uses DB or XML or SHMOP, it's irrelvent to the end result but keeping data properly organized in domain specific data stores will help keep your code clean and organized and ultimately make your application better, IMHO.
Cheers,
Alex