Форум: "Прочее";
Текущий архив: 2007.10.14;
Скачать: [xml.tar.bz2];
ВнизХранение настроек. Найти похожие ветки
← →
zdm77 (2007-09-13 13:41) [0]*.INI для хранения настроеек - это конечно хорошо... где их будем хранить? ../INI ? замечательно, но если прога инстолится по пути c:\programm files\qqq и машина в домене, а юзер просто юзер, то у него не будет прав на перезапись файла. понятно, что можно сделать что-то вроде настроечной формы, и там указать сеттинги по другим путям, либо делать это от имени админа (вроде можно, но как не знаю). И опять-же, в INI храним настройки конкретно последнего залогиненного юзера... Можно еще конечно каждому юзеру при первом входе создать свой INI(..\"user_name.ini"). Но помнится, что траблы все равно возникали. Дык вот, все равно склоняюсь к созданию в БД типа такого. таблицы. 1. Settings (поля ID, ID_USER, ID_PARAM) 2. PAram_Setting (id, name_param) ..ну и связка setting.id_param=param_setting.id... Многие знакомые коллеги отговаривают... а почему не пойму. Рост БД?...да лан, фигня, ничтожен. Зато гораздо проще работать с наборами данных чем с файлами... может и ошибаюсь. Переубедите!
← →
clickmaker © (2007-09-13 13:43) [1]а почему не реестр?
← →
boa_kaa © (2007-09-13 13:44) [2]а такой путь не канает? C:\Documents and Settings\SomeUser\Application Data\MyAPP
← →
Админ (2007-09-13 13:51) [3]Я недавно переделывал проект - все что скидывалось в INI теперь хранится в БД (давно хотел переделать).
Теперь любой пользователь зайдя в программу с любой машины использует свои настройки.
← →
zdm77 (2007-09-13 13:52) [4]Спасибо. Вариантов много на самом деле. Но я хотел услышать, контраргументы в отношении хранения настроек в БД.
← →
Desdechado © (2007-09-13 13:53) [5]> склоняюсь к созданию в БД типа такого
из пушки по воробьям?
лишнее место для возникновения проблем: движки БД, проблемы с коннектом, раздача прав
ну, и БД тоже должна где-то лежать, куда будут права у всех
← →
wicked © (2007-09-13 13:54) [6]
> Но я хотел услышать, контраргументы в отношении хранения
> настроек в БД.
лёгко... настройки для подключения к БД - главный контраргумент
особенно, если аппликация небольшая, а БД может быть несколько
хотя сам способ хранения настроек в БД очень хорош
← →
Desdechado © (2007-09-13 13:54) [7]> Админ (13.09.07 13:51) [3]
Здесь ключевое слово - "с любой машины". Но ситуация появления пользователя на чужой машине не такая уж частая.
← →
zdm77 (2007-09-13 13:55) [8]
> clickmaker © (13.09.07 13:43) [1]
> а почему не реестр?
Падение ОС и ее переустановка приведет и к падению реестра соответственно. А за БД проще следить и бэкапить чем каждую локальную юзерскую машину. Это тоже реализуемо, но с одним файлом БД как-то проще чем уследить за всеми лок. машинами... Не уточнил БД - FireBird. Хотя это не принципиально.
← →
zdm77 (2007-09-13 13:58) [9]
> wicked © (13.09.07 13:54) [6]
>
> > Но я хотел услышать, контраргументы в отношении хранения
>
> > настроек в БД.
>
> лёгко... настройки для подключения к БД - главный контраргумент
а я принципиально настр. БД прописываю в exe... - лучший способ защиты от тиражирования :)
← →
Вася Правильный (2007-09-13 13:59) [10]
> - лучший способ защиты от тиражирования :)
а также получения геморроя при изменении конфигурации сети
← →
zdm77 (2007-09-13 14:01) [11]
> Вася Правильный (13.09.07 13:59) [10]
есть другие предложения, по бесплатной и наиболее эффективной защите? а имея код, в DataBase прописать другой айпишник - пара сек делов
← →
Вася Правильный (2007-09-13 14:05) [12]
> DataBase прописать другой айпишник - пара сек делов
и потом на 300 компов его копировать, а работа юзеров стоит...
← →
zdm77 (2007-09-13 14:10) [13]
> Вася Правильный (13.09.07 14:05) [12]
>
> > DataBase прописать другой айпишник - пара сек делов
>
> и потом на 300 компов его копировать, а работа юзеров стоит.
> ..
согласен, но изменения конфигурации сети - это скорее ислючение чем правило. Значительно чаще происходят обновления программ. Ни чего не поделаешь. И уж когда происходит изменение конф. сети, то по любому - это не просто. -Пошли все нафиг, целый день работать не будем! А запланированно. И, ну придется задержаться на работе (не привыкать) , перестроить конфиг сети и переустановить ПО. Опять-же, юзая инстоллятор - даже 300 компов - не такой-уж и гемор.
← →
clickmaker © (2007-09-13 14:12) [14]
> перестроить конфиг сети и переустановить ПО. Опять-же, юзая
> инстоллятор - даже 300 компов - не такой-уж и гемор
для своего ПО можно автообновлялку написать, чтобы с шары качнула новую версию, когда она там появится
Мы так делали - удобно
← →
evvcom © (2007-09-13 14:15) [15]
> Desdechado © (13.09.07 13:53) [5]
Я так понял, у него приложение для работы с СУБД. Если так, то почему бы и нет? Хотя все равно надо взвесить все за и против. Если же не СУБД-шное приложение, то действительно такой огород ни к чему.
У меня к примеру сейчас СУБД-проект, но пользовательские настройки (размеры, местоположение форм, последние значения фильтров, отображаемые столбцы в гридах) лежат в HKCU.
← →
zdm77 (2007-09-13 14:15) [16]
> clickmaker © (13.09.07 14:12) [14]
Енто тож понятно... И как-раз опровергает аргументы Василия. Я все хочу контраргументы услышать. Ты как мастер, как сам предпочитаешь в своих прогах хранить настры?
← →
Empleado © (2007-09-13 14:15) [17]
> zdm77 (13.09.07 13:55) [8]
>
> > clickmaker © (13.09.07 13:43) [1]
> > а почему не реестр?
>
> Падение ОС и ее переустановка приведет и к падению реестра
> соответственно. А за БД проще следить и бэкапить чем каждую
> локальную юзерскую машину. Это тоже реализуемо, но с одним
> файлом БД как-то проще чем уследить за всеми лок. машинами.
> ..
Кстати, еще никто не отменял Roaming Profiles?
← →
zdm77 (2007-09-13 14:16) [18]
> evvcom © (13.09.07 14:15) [15]
я похож на идиота? конечно СУБД-шное
← →
zdm77 (2007-09-13 14:18) [19]
> Empleado © (13.09.07 14:15) [17]
Господа, ключевой фразой было услышать, почему несколько людей меня отговаривали от хранения настроек в БД. А не про перемещаемые профили и прочее.....
← →
clickmaker © (2007-09-13 14:19) [20]
> [16] zdm77 (13.09.07 14:15)
в коммерческих - в основном в реестре. Но есть проект ДотНетовский, где что-то типа профиля в базе - UserDefaults так называемые + xml на клиенте. В xml хранятся UIшные настройки: ширина колоночек всяких, сортировка...
В личных поделках совмещаю ini и реестр иногда, чтоб юзер мог выбрать сам
← →
sdts (2007-09-13 14:25) [21]
> clickmaker © (13.09.07 14:19) [20]
> Но есть проект ДотНетовский
посмотрите тут http://msdn2.microsoft.com/en-us/library/0zszyc6e.aspx
← →
clickmaker © (2007-09-13 14:28) [22]
> [21] sdts (13.09.07 14:25)
и так тоже делали
← →
zdm77 (2007-09-13 14:31) [23]Спасибо за участие. Но переубеждения все-таки не услышал. Объявление перменных, записи в uses, все-таки не очень-то удобная работа с файлами по сравнению с записями в БД, возможная нехватка прав... соответственно ведущих к пусть и небольшому но все-таки затрату системных ресурсов, проверки залогиневшись обычным пользователем...и т.д. Минусы есть и в хранении в БД, но как-то меркнут они, по сравнению с работой с файлами. К тому-же юзеры объявлены в БД...и как-то все гармонично связывается....
← →
zdm77 (2007-09-13 14:33) [24]в дотнет - я в обще ноль... по этому тут и говорить ни чего не буду...
← →
evvcom © (2007-09-13 14:39) [25]
> а имея код, в DataBase прописать другой айпишник - пара
> сек делов
Когда ты уволишься, на твое место придет другой программер. И для него это будет уже не пара сек делов, потому как до этого еще надо додуматься! Ему придется лазить по твоему коду, искать, откуда ж ты достаешь эту инфу? И вот он будет тебя материть по чем свет стоит и горевать, что не успел тебе руки выдрать за такие настройки!
> чтобы с шары качнула новую версию, когда она там появится
> Мы так делали - удобно
Вот именно так и делаем. И качаем не только экзешник, но и tnsnames.ora (ораклисты знают, что это), необходимые ini, а также шаблоны отчетов Crystal Reports. Потому сейчас об обновлении ПО, а также о перенастройке конфигурации сети голова совсем не болит.
← →
clickmaker © (2007-09-13 14:40) [26]в одном из проектов вообще был такой xml примерно
<Users><SettingItem><UserID>username</UserID> .... настройки </SettingItem>...</Users>
Т.е. такая вот самопальная реализация профилей для нескольких юзеров. Можно, конечно, и в Д так сделать, благо XMLDocument есть
Но лично мне такой путь не очень...
← →
zdm77 (2007-09-13 14:42) [27]
> evvcom © (13.09.07 14:39) [25]
>
> > а имея код, в DataBase прописать другой айпишник - пара
>
> > сек делов
>
> Когда ты уволишься, на твое место придет другой программер.
> И для него это будет уже не пара сек делов, потому как
> до этого еще надо додуматься! Ему придется лазить по твоему
> коду, искать, откуда ж ты достаешь эту инфу? И вот он будет
> тебя материть по чем свет стоит и горевать, что не успел
> тебе руки выдрать за такие настройки!
а мне пофиг на других, уволюсь, пусть перазаключат договор на сопровождение. А код свой я не отдам
← →
evvcom © (2007-09-13 14:45) [28]
> zdm77 (13.09.07 14:16) [18]
> > evvcom © (13.09.07 14:15) [15]
> я похож на идиота? конечно СУБД-шное
Заметь, не я это сказал :)
Причем удивляют еще твои замечания по поводу недостаточности прав при хранении настроек в ini файлах. Так держать эти инишки нужно в правильном месте.
← →
zdm77 (2007-09-13 14:46) [29]а если и отдам, то блин, не надо ни где лазить, а просто зайти в DataModule, найти DataBase и написать рильный адрес... .вот задача-то конечно не разрешимая :)
← →
evvcom © (2007-09-13 14:46) [30]
> А код свой я не отдам
А ты уверен, что он твой? Ты работаешь на работодателя, на его оборудовании, он тебе платит зарплату. Авторство твое, но код, извини, уже не твой.
← →
vpbar © (2007-09-13 14:51) [31]>>evvcom © (13.09.07 14:46) [30]
Это так если программа написана по договору (заказу) или как выполнение должностных обязаностей.
А если от там сисадмин, например, а програмку написал (в свободное время) для себя, и от щедрот свойх поделился с работодателем, то работадатель на его код прав не имеет.
← →
vpbar © (2007-09-13 14:51) [32]>>evvcom © (13.09.07 14:46) [30]
Это так если программа написана по договору (заказу) или как выполнение должностных обязаностей.
А если от там сисадмин, например, а програмку написал (в свободное время) для себя, и от щедрот свойх поделился с работодателем, то работадатель на его код прав не имеет.
← →
zdm77 (2007-09-13 14:56) [33]
> evvcom © (13.09.07 14:45) [28]
Специально для Вас. Хотя главный вопрос я озвучил уже не раз. Не проблема хранения, а контраргументы против хранения настроек в БД!
Среда разработки - BDS2006
БД- FireBird
Структура сети - доменная аутентификация
Коннект - FibPlus компоненты
Datamodule - 6 шт.
FibDataBase - на "первом" DataModule (он и задает пути к БД).
Последователю, придется, если и произойдут изменения в сети. Зайти в DataModule и прописать новые настройки в FibDataBase и все!!! С другой стороны, если я не хочу свободно передавать коды или чтобы все кому не лень распростроняли мое ПО, мне достаточно узнать IP будующего сервера и путь к БД. Внести изменения, при чем все визуально и перекомпилить проект. Но опять-же вопрос не о том.
← →
zdm77 (2007-09-13 14:56) [34]
> vpbar © (13.09.07 14:51) [32]
ты прям как в воду смотришь!!!
← →
Anatoly Podgoretsky © (2007-09-13 14:58) [35]Если настройки должны применяться еще до логина пользователя, то база плохой путь.
http://podgoretsky.com/ftp/Language/nps/ru.delphi.html#N146
Добавить поправки для Висты
← →
zdm77 (2007-09-13 15:01) [36]спасибо Анатолий. хороший FAQ , добавлю в избранное. Ну вот вышла виста, потом еще чо=нить выйдет....и вечно думать о способе аутентификации юзеров и где, как и что хранится. А с БД все понятно на момент создания и распределения прав.
← →
iZEN © (2007-09-13 15:06) [37]
> zdm77 (13.09.07 13:41)
>
> *.INI для хранения настроеек - это конечно хорошо... где
> их будем хранить?
В каталоге ~/.config/
Естественно!
← →
Eraser © (2007-09-13 15:09) [38]
> zdm77 (13.09.07 13:4
настройки хранить в xml, который, в свою очередь, хранить в C:\Documents and Settings\и т.д.
обновлять через утилиту обновлений в 2003 сервере + msi.
реестр это прошлый век, а ini - позапрошлый :-)
← →
iZEN © (2007-09-13 15:13) [39]
> Eraser © (13.09.07 15:09) [38]
> обновлять через утилиту обновлений в 2003 сервере + msi.
msi только для WindowsXP/Vista.
Уж лучше использовать CVS.
← →
evvcom © (2007-09-13 15:15) [40]Хозяин - барин. Переубеждать не собираюсь. Но я бы за поддержку такой программы не взялся, лучше уволиться, имхо.
Страницы: 1 2 3 4 вся ветка
Форум: "Прочее";
Текущий архив: 2007.10.14;
Скачать: [xml.tar.bz2];
Память: 0.56 MB
Время: 0.045 c