хранение пользовательских настроек программы в БД. идеология

← →
ari_9 (2007-11-29 12:29) [0]

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

вопрос не в том, как можно сделать - я сам вижу много вариантов, а как сделать правильно

пока предполагаю так:

таблица Parameters
поля
Parameter_ID
Parameter_Parental_ID
Parameter_Name
Parameter_Type
Parameter_Visible

Таблица Users_Parameters
поля
User_ID
Parameter_ID
Parameter_Value - VARCHAR

настройки, используемые мной и не показываемые пользователю: связаны с программными компонентами только по ID, эти ID жестко заданы мной и в коде проекта, и в БД (это несколько напрягает). поле Parameter_Name смысловой нагрузки не несет. загружаю и пишу их из/в Users_Parameters, там где нужно выполнить преобразование типов, беру Parameter_Type из Parameters

настройки, задаваемые пользователем: у пользователя рисую дерево на основе Parameters, куда входят все ветки с Parameter_Visible = 1 и с родительскими Parameter_Visible = 1. редактировать в дереве не позволяю, по клику открываю окошко с параметром (заодно в зависимости от Parameter_Type выставляю маску дбэдита, пишу данные в Users_Parameters)

что не нравится в этой схеме :
1. если како-то парметр у меня задается пользователем не в общем окне настроек, а где-то в других формах (ну, например, последняя строка поиска), то много повторяющегося кода типа параметр с ID равным Tag"у компонета подгрузить, параметр записать ...
2. слишком много данных из БД оказывается внутри кода (ID всех параметров)
3. если понадобится в будущем дать пользователю возможность добавлять свои настройки (а не только редактировать параметры заданных разработчиком), не ясно как это сделать красиво

думаю, такую задачу решали многие, интересно было бы знать к чему пришли в итоге

← →
Sergey13 © (2007-11-29 12:45) [1]

> [0] ari_9 (29.11.07 12:29)
> 3. если понадобится в будущем дать пользователю возможность
> добавлять свои настройки

Это как? А кто их обрабатывать будет? ИИ?

← →
Sergey13 © (2007-11-29 12:51) [2]

Вместо Parameter_ID и Parameter_Name (которые "смысловой нагрузки не несет"), я бы сделал Parameter_CODE и присваивал бы ему осмысленные значения. ИМХО значительно улучшит читаемость кода и не даст самому запутаться.

← →
ari_9 (2007-11-29 13:13) [3]

Sergey13

Parameter_CODE это хорошо, да. подумаю. единственный минус, придется его в коде писать руками, а не в дизайнере на тэги развешивать

Это как? А кто их обрабатывать будет? ИИ?

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

← →
Sergey13 © (2007-11-29 13:36) [4]

> [3] ari_9 (29.11.07 13:13)
> естественно, пользователь может добавить пару код-домен.

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

← →
Anatoly Podgoretsky © (2007-11-29 14:24) [5]

> Sergey13 (29.11.2007 13:36:04) [4]

Это тоже можно, только потом разработчик должен разработать обработчик.

> Sergey13 (29.11.2007 14:41:06) [6]

Я тоже.
И смотрю на это обсуждение и душа протестует.

← →
ari_9 (2007-11-29 20:42) [8]

Sergey13

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

) нет, не до такой степени клинично, конечно

хранение пользовательских настроек программы в БД. идеология Найти похожие ветки