Сергей Васкецов
Натягивается обновление на систему в виде патча, меняющего только данные в БД (скрипт). Кроме самих данных необходимо изменить соответствующим образом "профили" всех юзеров, чтобы они также соответствовали новой версии.
я бы согласился, если бы были простые примеры " версионных профилей".
Примеры ненужных парам в БД я приводил.

было счастье, да несчастье помогло.
Как раз сейчас встала задача конфигурирования параметра
http://WebServer:8008/

данная строка используется на клиенте в ослике встроенном в программу.

- в центральное окно входа в БД ЭТО нет смысла пихать, т.к. на каждом клиенте этот парам ненужен.

- В БД и городить админскую прогу лень ......

- В БД и в виде скрипта для опытного пользователя-админа? Задаст новое значение при смене WebServera.

кто как делает?

______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

ModelR
приведённая вами структура (один ко многим) имеет место только если атрибут периодический?
Если нет периодики то можно плоскую таблицу?
- сиквел поддерживал вариант в типе поля. Используется ли это при проектировании (чтобы EAV не городить)?

ну, у меня в данном конкретном проекте, данный параметр хранить отдельно от БД некрасиво по причине безопасности.

Несмотря на то, что параметр не имеет отношения к БД, при его хранении отдельно, есть риск замены адреса вэб сервера на sex.com или аналогичные.
Результат будет плачевный для всех клиентов в сети ).

При хранении в СУБД это проще решается и контролируется.

Поэтому всё очень зависит от конкретики. В прошлом проекте мы немогли дампом накатывать окружение и параметры, т.к. были пользовательские шаблоны-файлы с горячими кнопками, папап-меню, панелями и т.д.


______________________________________________
Вы имеете право хранить молчание! Всё что Вы скажете может быть использовано против Вас в суде!

ModelR
Не обязательно периодический (в смысле 1С). Тама и другие причины указаны.

не нашёл

ModelR ModelRПараметры могут [...] зависеть от конкретного пользователя , конкретного периода, функционального блока (логического АРМа), и каких-то еще специфических для приложения вещей, сотавляющих текущий контекст.

спс.
понял (у меня в примере можно упростить).

mcureenab Petro123Несмотря на то, что параметр не имеет отношения к БД, при его хранении отдельно, есть риск замены адреса вэб сервера на sex.com или аналогичные.
Результат будет плачевный для всех клиентов в сети ).

При хранении в СУБД это проще решается и контролируется.



При чём тут "имеет отношение или не имеет"? Значение параметра, это данные. Для хранения данных люди придумали (в общем смысле слова) БД. Так почему бы не воспользоваться достижениями человеческой мысли и поэкономить свою мысль?
Даже если по каким то причинам параметрические данные должны храниться на узле удалённом от сервера БД, то и в этом случае имеет смысл хранить их в БД, чтобы по мере надобности можно было копировать их из БД на локальный узел, не теряя при этом возможность централизованного управления системой.
я за плюрализм :)
Не люблю когда есть только один вид колбасы.
БД при разаработке ПО как минимум:

- текстовый файл (xml-ini)
- в OS реестр
- в OS двоичный файл (вплоть до DLL в памяти загруженной с расшаренной папки)
- в OS служба каталога
- в OS СОМ-хранилища - Structured Storage
- ....
- СУБД
Поэтому случаи бывают разными и последний пункт - не панацея.