Хранение настроек.

[Coffin]

Хранение настроек.

Хочется знать, как же всетаки это лучше делать ?
Вообщем что б настройки где-то хранились , и через визуальный интерфейс их можно было отредактировать и сохранить.
Предположим будет храниться в config.php
это надо будет каждый раз переписывать файл по строкам, что бы сохранить настрйоки ?
такая же ерунда с ini ?

или я туплю и есть более простые способы

 

[shtogrin]

Просто каждый раз заново генерировать файл целиком

 

[Frol]

будет так -- как реализуешь.

 

[Coffin]

Автор оригинала: Frol
будет так -- как реализуешь.

Твой совет по реализации ?

 

[440hz]

shtogrin

всякие там локальные настройки относящиемя к хостингу
- база
- пути
- URLs

хранить в файле

все остальное вывнести в базу

 

[leeroy]

Напиши API =) По мне , так ты тупиш...

 

[zerkms]

leeroy
корзина по вашим постам плачет, угу

 

[_vampiro_]

[m]fwrite[/m]
[m]file_get_contents[/m]
[m]serialize[/m]
вот и вся "API" ;-)

 

[Gorynych]

Coffin

это был вопрос по стратегии?

вариант 1: хранение в базе данных

"минусы"

- для чтения и прочего нужны а) соденение с БД; б) настройки соединения с БД храняться отдельно от остальных

вариант 2: хранение в файле

имеет смысл рассматривать вариант размещения файла(ов) - вне DOCUMENT_ROOT

"минусы"

- потенциальная доступность файла для тех, кто имеет доступ к дисковому пространству сервера (служба тех.поддержки и т.п.).

------------

и тот и другой случай имеют несколько очевидных минусов (кстати, скорость работы я не рассматриваю, потому что ее величина зависит от того, насколько Вы там накрутите всего в конечном итоге)

на что стоит обратить внимание при выборе стратегии (имхо):

- предполагает ли ваш проект авторизацию пользователя? Если "да", то какой способ авторизации и хранения данных Вы используете?

Если данные об авторизации храняться в БД, то и настройки стоит хранить там же (и так, и так вы будете обращаться к базе). А вот если регистрация/авторизация пользователей на ресурсе не предполагается/не обязательна - тогда имеет смысл подумать/рассмотреть плюсы и минусы вариантов не завязанных на базу данных.

 

[_vampiro_]

хм... если надо безопасность - включите в API функцию [m]crypt[/m]

Gorynych
- потенциальная доступность файла для тех, кто имеет доступ к дисковому пространству сервера (служба тех.поддержки и т.п.).(с)

Особенно хорошо прятать от них данные в БД, учитывая, что пароль от неё хранится на том же "дисковом пространстве"сервера.

 

[Gorynych]

_vampiro_

помимо тех.поддержки хостера доступ к дисковому пространству хостинговой машины могут иметь и другие разработчики, коллеги и просто пользователи (если предполагается доступ пользователей сайта по FTP). Проекты и задачи бывают разными, ага?

 

[Coffin]

да там не идет речь о каких-то секретных настройках
Вообщем речь в больше сетепени шла о настройках дизайна...
что каждый юзер может настроить цветовую гамму и тд, под себя...
только вот я думаю как это все базе хранить, если там будет скажем 100 различных настроек... это что, 100 полей что ли создавать ?
или легче всетаки скажем изначально сделать файл стандартной конфигурации , а потом , если юзер изменил настроку, то создать файл конфига и назвать его ID_юзера.cfg
? такой вариант покатит ?

 

[Gorynych]

Coffin

создавать или не создавать 100 полей - это уже вопросы к разработке API.

из собственного опыта могу сказать, что для системы, в которой мне нужно периодически сохранять окружение сеанса (т.е. сессионное окружение), я предпочитаю сбрасывать весь дамп в поле типа BLOB используя БД как хранилище, а сам разбор/структуризацию данных оставлять за PHP.

 

[TRL]

есть ещё один вариант... использовать готовый клас для работы с ини

http://www.phpclasses.org/browse/package/1726.html

Хор. придумано, тебе собственно говоря ничгео не надо самому переписывать....

 

[Coffin]

Ок, спасиб поглядим, подумаем, сделаем