I use a settings table with a simple key/value pair to get/set app settings from backoffice. Since this is settings, individual rows belong to different type of data and business rule. I couldn’t find a better way to manage validation rules (neither user interface because one setting may store date that will require calender, whereas other setting require slider and so on). For now, I’m doing a dirty if/else to render UI controls and requested admin not to enter bad values (?!). Can you please suggest a good way to get ride of my bad habits?
[*]I’d use client-side validation with jQuery Validate (bassistance), and re-validate on the server-side, using plain PHP.
[*]I’d try one of these settings / config extensions available for Yii, maybe they do that already
[*]I’d have a table with key as columns. So a row would be the whole config. That way, you can use gii for the model, crud, validation, etc. and you could also increment the config version each time the admin makes a change in the config. ie surely some biz rules rely on the config, and maybe a snapshot of the config at a given time. So, instead of overwriting old values, you just create a new row, and link any such biz rule to the config id.
I would go with suggestion 1). Suggestion 2) I tried the settings extension, it violates db rules (holds more than one value in a single field, don’t provide any validation / UI facilities either). Suggestion 3) Altering a table for adding/removing config? Seems not very good. There might be better solution.
Is it a strict requirement for your application to store that data in a relational database? When I have to store key-value pairs (and there are no more than a few dozens of them) I simply store them in a file using either var_export() or serialize() and access them via a model derived from CFormModel. Model class must have a load() and a save() method to read/write properties from/to the file and may implement the Singleton pattern. Relational databases are simply not suited for key-value data, imho.
EDIT: Concurrent accesses may cause some difficulties, of course, but for configuration data, that is not likely to change in every second, it should work.
