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

Petro123Первые лучше хранить в HKEY_USER - реестра
Еще чего не хватало. Пользователь только с одного места может работать? А если это КПК?

Роман Дынникесть более подходящие места - файлы конфигураци (xml, ini)
Осталось найти множество существенных отличий между чтением файла xml и поля xml из БД.
Не хочу вдаваться в подробности, но как практик, предпочитаю параметры, не связанные непосредственно с рабочим местом, хранить все же в БД по ряду причин.

Роман Дынник Сергей Васкецов
Осталось найти множество существенных отличий между чтением файла xml и поля xml из БД.
Не хочу вдаваться в подробности, но как практик, предпочитаю параметры, не связанные непосредственно с рабочим местом, хранить все же в БД по ряду причин.
Ну пусть это пользователь попробует, не имея под рукой QA/UI и если вдруг пропал доступ к серверу БД, прочитать и поправить xml-поле в БД:)
Не вижу вообще необходимости, если у пользователя пропал доступ к БД, давать ему возможность что-то делать в обход системы, так как "вдруг" обычно доступ не пропадает.

Расшифрую насчет "практика". Я прежде всего имею в виду ситуацию, когда для анализа какой-либо неисправности необходимо иметь полную копию окружения, в котором работает пользователь, а также сохранять и восстанавливать данное окружение дампами. Иметь отдельные файлы для настроек в такой ситуации крайне неудобно по сравнению с хранением информации, пусть даже относящейся исключительно к конкретному пользователю, в рабочей БД. Также при хранении в БД настроек окружения пользователя повышается удобство работы с такими "профилями", так как можно выполнять настройку "профиля по умолчанию", произвольное "копирование" (в том числе и частичное, отдельных элементов) таких "профилей", автоматическое обновление данных в "профилях" при обновлении системы, разграничение прав доступа к атрибутам "профилей", и т.п., что куда более сложно в случае расположения "профилей" в файлах где попало.

ModelRОн должен догадаться позвонить в техподдержку по мобильнику вынув батарейку:).
Не очень понял смысл фразы. Это что-то типа "поздно пить боржоми"?

RangilПосудите сами. Если хранить параметры в файле (даже жёсто связанным с сервером БД), доступ к которому возможен даже при остановленном сервере БД, то это даст возможность алгоритмам прочитать их и сделать попытку выполнения дальнейших действий. Остается надеятся, что не произойдет зависания клиента, выполняющего алгоритм. Если же те же параметры будут находится на сервере БД, то клиент не сможет даже соединится с ним не говоря уже о чтении параметров и произойдет предупреждение клиента о невозможности соединения с сервером БД. Это инкапсуляция данных для работы с серверными алгоритмами и общесистемных данных, которые будут использоваться серверными объектами. Как класс в языках программирования.
Почти ничего не понял из написанного Вами. Можете перевести это на русский язык?

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

Petro123простые примеры " версионных профилей"
Не понимаю, что такое "версионный профиль". Я про ситуации, когда надо покопаться в профиле пользователя при натягивании обновления.

Petro123Примеры ненужных парам в БД я приводил.
Если Вы про "А если это параметр - размер формы в пикселях? :))", то с этим я в целом согласен. Но я ж и не утверждал, что вообще все должно быть в БД. Конкретные пиксели конкретной формы - это имеет больше отношения к рабочему месту, разрешению экрана, чем к пользователю. Впрочем, ситуации, в которых даже размер и положение элементов управления, а не только форм, необходимо хранить в БД, также имеют право на существование.

mcureenabЕсть варианты, когда в системе присутствует служба каталога, в которой можно централизованно хранить параметры, которые в базе данных будут бесполезны, но такая служба, это тоже своего рода БД.
Как, кстати, и реестр.