[eluser]jdfwarrior[/eluser]
[quote author="Phil Sturgeon" date="1246966268"]I do this in PyroCMS and it's not too bad. With a spot of DB caching and storing them results in the library object as you go (meaning two requests for site_name do not fire off too queries) I haven't really noticed an issue with speed.
I spend all day working with a CMS that runs about 50 database connections and runs over 100 queries just for basic page layouts and content... I really don't think a few 1 line SELECTs are going to hurt anything.
sql
Code:
CREATE TABLE `settings` (
`slug` varchar(30) collate utf8_unicode_ci NOT NULL,
`title` varchar(100) collate utf8_unicode_ci NOT NULL,
`description` text collate utf8_unicode_ci NOT NULL,
`type` set('text','textarea','password','select','select-multiple','radio','checkbox') collate utf8_unicode_ci NOT NULL,
`default` varchar(255) collate utf8_unicode_ci NOT NULL,
`value` varchar(255) collate utf8_unicode_ci NOT NULL,
`options` varchar(255) collate utf8_unicode_ci NOT NULL,
`is_required` tinyint(1) NOT NULL,
`is_gui` tinyint(1) NOT NULL,
`module` varchar(50) collate utf8_unicode_ci NOT NULL,
PRIMARY KEY (`slug`),
UNIQUE KEY `unique - slug` (`slug`),
KEY `index - slug` (`slug`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci COMMENT='Stores all sorts of settings for the admin to change';
You can mostly ignore is_gui and module, they are just to stop it showing up on the interface and module is a way to break down settings into tabs.
lib
model
Hope thats of some help.[/quote]
agreed.