Форум: "Прочее";
Текущий архив: 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]Хозяин - барин. Переубеждать не собираюсь. Но я бы за поддержку такой программы не взялся, лучше уволиться, имхо.
← →
zdm77 (2007-09-13 15:16) [41]
> Eraser © (13.09.07 15:09) [38]
1. c выходом новых ОС, дефолтовые пути юзеров меняются.
2. doc and sett - не факт! можно по разному настроить. И в конечном итоге - не известно как их настроит админ.
И главное, ну сколько можно повторять..... приведите контраргументы хранения в БД!!!!
> iZEN © (13.09.07 15:06) [37]
>
> > zdm77 (13.09.07 13:41)
> >
> > *.INI для хранения настроеек - это конечно хорошо... где
>
> > их будем хранить?
>
> В каталоге ~/.config/
> Естественно!
Естественно - спать не на потолке(одеяло спадает). В чем естественность?
← →
vpbar © (2007-09-13 15:22) [42]>>zdm77 (13.09.07 15:16) [41]
>>1. c выходом новых ОС, дефолтовые пути юзеров меняются.
ну и что. Исчезнет возможность их узнать?
>>2. doc and sett - не факт! можно по разному настроить. И в конечном итоге - не известно как их настроит админ.
А это то тут при чем. Есть конечно "программисты" которые ститают что и винда должна стоять только в с:\windows .
>>И главное, ну сколько можно повторять..... приведите контраргументы хранения в БД!!!!
У меня контраргументов нет. Если прога работает с БД то почемубы настройки там не хранить.
← →
evvcom © (2007-09-13 15:26) [43]
> Ну вот вышла виста, потом еще чо=нить выйдет....и вечно
> думать о способе аутентификации юзеров и где, как и что
> хранится.
Нет, не нужно, если играть по правилам винды.
> 1. c выходом новых ОС, дефолтовые пути юзеров меняются.
И что? А ты думаешь все программы жестко пишут в D&S? Эти пути вычисляются.
> приведите контраргументы хранения в БД!!!!
Зачем? Храни в БД, если считаешь для себя, что так удобнее.
← →
Eraser © (2007-09-13 15:29) [44]
> vpbar © (13.09.07 15:22) [42]
> Если прога работает с БД то почемубы настройки там не хранить.
чтобы не смешивать мух с котлетами. Хоть программа и работает с БД, но эти сущности весьма ограничены друг от друга. Не стоит хранить вместе с данными какие-то служебные настройки программы. Тем более что может потребоваться ограничеть доступ к настройкам не админам к примеру.. вот тогда и появятся проблемы. Да и где сами настройки подключения к БД хранить то? ) а там пароль еще нужен )
← →
Prohodil Mimo © (2007-09-13 15:31) [45]Путь к базе храню в регистре (в software), там же имя последнего зашедшего пользователя и язык интерфейса по умолчанию.
Все остальные настройки, которые касаются конкретного пользователя храню в базе.
Пользователь идентифицируется до создания всех форм, а потому
> Если настройки должны применяться еще до логина
> пользователя, то база плохой путь
не мешает.
← →
iZEN © (2007-09-13 15:38) [46]
> zdm77 (13.09.07 15:16) [41]
> > > *.INI для хранения настроеек - это конечно хорошо...
> где
> >
> > > их будем хранить?
> >
> > В каталоге ~/.config/
> > Естественно!
>
>
> Естественно - спать не на потолке(одеяло спадает). В чем
> естественность?
В том, что пользовательские данные должны хранится в его профиле/домашнем каталоге и больше нигде. Разве это неочевидно? :O
← →
zdm77 (2007-09-13 15:42) [47]
> Eraser © (13.09.07 15:29) [44]
1. Про хранение путей к БД уже говорил, в exe вшито в DataBase компоненте.
2. Почему не стоит так хранить? т.е. смешивать данные со служебной инфой? я не вижу в этом аксиомы, точнее не услышал опять аргументов.
3. В БД есть users и roles в чем трабла-то?
← →
iZEN © (2007-09-13 15:44) [48]
> Eraser © (13.09.07 15:09) [38]
>
>
> > zdm77 (13.09.07 13:4
>
> настройки хранить в xml,
Ни в коем случае!
plain-text -- шашэфсйо, иначе разоришься на XML-парсерах.
← →
zdm77 (2007-09-13 15:44) [49]
> iZEN © (13.09.07 15:38) [46]
Очевидно, но той-же очивидности я могу спокойно добится (имеется домен и перемещаемые профили или нет, винда любая...) с помощью БД
← →
iZEN © (2007-09-13 15:47) [50]
> zdm77 (13.09.07 15:44) [49]
>
>
> > iZEN © (13.09.07 15:38) [46]
>
> Очевидно, но той-же очивидности я могу спокойно добится
> (имеется домен и перемещаемые профили или нет, винда любая.
> ..) с помощью БД
Да, не спорю. Можно поднять Oracle на Red-Hat и завести аналог ActiveDirectory на Novell SLES. В сети. С доменами и пользователями Windows. Чтобы хранить структуру из десятка сточек: свойство=значение
из пушки по воробьям...
← →
Anatoly Podgoretsky © (2007-09-13 15:48) [51]
> 1. c выходом новых ОС, дефолтовые пути юзеров меняются.
> 2. doc and sett - не факт! можно по разному настроить. И
> в конечном итоге - не известно как их настроит админ.
Ты что пишешь по путям, больше так не делай, спроси ОС пусть она скажет куда, что писать.
← →
Админ (2007-09-13 15:48) [52]zdm77 (13.09.07 14:18) [19]
Господа, ключевой фразой было услышать, почему несколько людей меня отговаривали от хранения настроек в БД. А не про перемещаемые профили и прочее.....
А люди что говорят?
← →
Вася Правильный (2007-09-13 15:51) [53]> пользовательские данные должны хранится в его профиле/домашнем
> каталоге и больше нигде
если юзер может работать то на одном компе, то на другом, то на третьем, то смысл хранить в БД есть, хотя можно хранить и в перемещаемом профиле (тоже БД фактически)
← →
Eraser © (2007-09-13 15:55) [54]
> zdm77 (13.09.07 15:42) [47]
> Про хранение путей к БД уже говорил, в exe вшито в DataBase
> компоненте.
конечно от задачи завист, но, в общем случае, это дурной тон.
> 2. Почему не стоит так хранить? т.е. смешивать данные со
> служебной инфой? я не вижу в этом аксиомы, точнее не услышал
> опять аргументов.
к примеру понадобится работать с другой БД, или БД банально упадет, что тогда делать?
к тому же, в случае хранения настроек в БД, они будут доступны третьим лицам, которым совершенно не обязательно их знать.
в общем никаких приемуществ такого подхода я не вижу, одни минусы.
← →
Eraser © (2007-09-13 15:57) [55]
> iZEN © (13.09.07 15:44) [48]
> иначе разоришься на XML-парсерах.
в виндовз, начиная с 2K, бесплатный есть, на ранние системы доустановить можно.
← →
zdm77 (2007-09-13 15:57) [56]
> Админ (13.09.07 15:48) [52]
Да в том то и дело, что ни чего кроме -ВОТ ДЕЛАТЬ НАДО ТАК!!! Я и хотел узнать почему у Вас.
Пока общались зделал следующие заключения.
Минусы хранения в БД настроек.
1. Настройка путей к БД до коннекта.
2. Мешание мух с котлетами, настройки и данные.
Опровержение.
1. Можно превратить в плюс. Не сложные настройки одного компонента, имея код перенастроить под клиента. И соответственно как защита от копирования ПО сработает.
2. Ни чего страшного в паре таблиц не увидел...или точнее аргументов не услышал.
Плюсы
1. Легкость обращения к данным.
2. Не нужно думать о путях хранения и правах пользователей.
3. ...да плюсы можно перечислять очень долго...
> iZEN © (13.09.07 15:47) [50]
Open-Ldap ---вот рильная тема.... а еще поднять mail-server на Линухе, то-же тема.... Тока вот, как-то не адекватный ты пример привел. Или кто-то может поспорить, что данные в табличку внести, труднее, чем работать с файлом?
← →
evvcom © (2007-09-13 16:14) [57]
> И соответственно как защита от копирования ПО сработает.
Ломается начинающим хакером в 5 секунд (в масштабе тех твоих 2-х :))
← →
zdm77 (2007-09-13 16:16) [58]
> evvcom © (13.09.07 16:14) [57]
извини, мож я торможу. Но как ты изменишь пути к БД не имея кода?
← →
Eraser © (2007-09-13 16:18) [59]
> zdm77 (13.09.07 16:16) [58]
молча и быстро, особенно если программа не запакована )
← →
evvcom © (2007-09-13 16:19) [60]
> Но как ты изменишь пути к БД не имея кода?
Как это "не имея"? Так exe-то есть! Вот тебе и код. :-)
Подрастешь - узнаешь.
← →
zdm77 (2007-09-13 16:22) [61]дизассемблеров толковых я мало встречал
← →
evvcom © (2007-09-13 16:22) [62]
> молча и быстро
еще попивая пивко и покуривая сигару :)
> zdm77
Ты чего, ни одного фильма про хакеров не смотрел? Там, конечно, многое приукрашено, но в принципе так примерно и делается. :)
← →
zdm77 (2007-09-13 16:23) [63]блин, да сломать все можно, это понятно. вопрос рентабильности сего мероприятия. И опять-же, вопрос был не к этому :( куда-то мы ушли
← →
vpbar © (2007-09-13 16:23) [64]zdm77 (13.09.07 16:22) [61]
OllyDbg -посмотри или IDA
А для того чтобы строчку поменять иногда достаточно текстового редактор
← →
evvcom © (2007-09-13 16:24) [65]
> дизассемблеров толковых я мало встречал
О! Ты вона какое слово знаешь. Ну так все же встречал!
← →
vpbar © (2007-09-13 16:24) [66]zdm77 (13.09.07 16:23) [63]
Мы пришли к тому что аргумент "защита от копирования" очень слабый.
← →
zdm77 (2007-09-13 16:28) [67]Хорошо, углублюсь в конкретику.
Прога работает с Бд. Масштабируемость проекта предусмотрена. Т.е. появляются разные новые задачки к ней. Заказчик может нанять конечно хакера, криво ломануть.... но нафига? Чужой, да еще и ломаный код- это жесть. Проще заключить договор со мной. Типа сейчас опровергаю себя не много. Но дело не в этом. Не защитой стоял основной вопрос!!!!!! А к защите, то можно этот путь использовать, как один из!!!
← →
zdm77 (2007-09-13 16:32) [68]
> vpbar © (13.09.07 16:24) [66]
> zdm77 (13.09.07 16:23) [63]
> Мы пришли к тому что аргумент "защита от копирования" очень
> слабый.
я не про защиту тут вопросы задавал!!! ну дошли, значит дошли. Давай на mail кину тебе exe, а ты скажи, какие адреса указаны в моей проге, смени на любой, перекомпиль. И если все заработает, респект тебе!!!!
← →
evvcom © (2007-09-13 16:32) [69]
> zdm77 (13.09.07 16:23) [63]
> блин, да сломать все можно, это понятно. вопрос рентабильности
> сего мероприятия
Сейчас еще и в экономику ударимся. Что такое рентабельность? Это отношение прибыли к затратам (в общих чертах). Какие здесь затраты? Я уже сказал, что 5 сек. Итого в деньгах затраты -> 0 (стремятся к 0). Если прибыль от твоей программы не -> 0, то рентабельность будет просто бешеной, ну а если прибыль -> 0, то, даже не ломая ее, нет смысла использовать. Как тебе такая экономика? :)
← →
Anatoly Podgoretsky © (2007-09-13 16:34) [70]> vpbar (13.09.2007 16:23:04) [64]
Я тоже знаю один инструмент, он и для взлома и вирус - это Блокнот
← →
clickmaker © (2007-09-13 16:35) [71]
> а ты скажи, какие адреса указаны в моей проге
127.0.0.1?
:)
← →
Anatoly Podgoretsky © (2007-09-13 16:35) [72]> zdm77 (13.09.2007 16:23:03) [63]
> И опять-же, вопрос был не к этому
Так ответы ты не слушаешь.
Анекдот про чукчу знаешь?
← →
evvcom © (2007-09-13 16:35) [73]
> криво ломануть
чего там криво ломать-то?
> Давай на mail кину тебе exe, а ты скажи, какие адреса указаны
> в моей проге, смени на любой, перекомпиль.
сколько заплатишь?
← →
Anatoly Podgoretsky © (2007-09-13 16:35) [74]> zdm77 (13.09.2007 16:32:08) [68]
Сколько?
← →
Anatoly Podgoretsky © (2007-09-13 16:37) [75]> evvcom (13.09.2007 16:35:13) [73]
> сколько заплатишь?
Наживу почуствовали, но думаю обломится.
← →
zdm77 (2007-09-13 16:37) [76]Ребят, пожалейте безумных ребят, создателей SAMBA. ACTIVE DIRECTORY существует уже где-то лет 8, в финал-релизе, а они на уровне NT4. Дезасемблируют по маляху винду.... Превратите ее в OpenSource, и будет Вам вечный респект
← →
zdm77 (2007-09-13 16:37) [77]
>
> clickmaker © (13.09.07 16:35) [71]
>
> > а ты скажи, какие адреса указаны в моей проге
>
> 127.0.0.1?
> :)
не угодал... не локалхост :)
← →
zdm77 (2007-09-13 16:41) [78]чо-то развели баян... :) Позвольте, как автору закрыть тему. Пару аргументов я услышал, но не переубедительных. Всем спасибо за участие!
← →
evvcom © (2007-09-13 16:44) [79]
> Наживу почуствовали, но думаю обломится
Ну вот, накаркал :)
← →
vpbar © (2007-09-13 16:45) [80]>>zdm77 (13.09.07 16:32) [68]
Тише, не нервничай так. Если хочешь давай. Попоробую разобрать на досуге. Но опыт у меня не большой в этом, так что может и не получится. Но все равно привязка к адресу БД - не очень надежная защита. Так что остается? А остается то что плюсов у хранения конфига в БД не больше чем у других способов. Ведь пункт "3. ...да плюсы можно перечислять очень долго..." можно приписать к чему угодно.
Впрочем и не меньше, ИМХО. Так что используй что тебе нравится. Нравится БД - так ипользуй её. Нравится в реестр лазить - пожалуйста.
>>Минусы есть и в хранении в БД, но как-то меркнут они, по сравнению с работой с файлами. К тому-же юзеры объявлены в БД...и как-то все гармонично связывается....
Раз гармонично связывается - так в чем проблема. Хотя невижу больших минусов по сравнению с файлами (В общем случае)
>Господа, ключевой фразой было услышать, почему несколько людей меня отговаривали от хранения настроек в БД.
Ну спроси ЭТИХ ЛЮДЕЙ почему ОНИ отговаривали. Если честно с телепатией и ясновидинием у меня плохо. Долго медитировать надо и все такое :) и ответить почему ЭТИ ЛЮДИ тебя отговаривали я не могу. Если кто и сможет так это в соседней ветке, про экстрасенсов.
← →
zdm77 (2007-09-13 16:50) [81]
> vpbar © (13.09.07 16:45) [80]
Если кто и сможет так это в соседней ветке, про экстрасенсов
:)
Я уж говорил, что ни кто ни чего толком ответить не может. Сам тоже по инерции использовал INI либо реестр, а тут вот задумался, а почему не в БД. Поэтому решил обратится к Вам, мастерам.
← →
Вася Правильный (2007-09-13 16:54) [82]короче, звучит как "держите меня семеро, я все равно его порву!"
← →
Anatoly Podgoretsky © (2007-09-13 16:58) [83]> zdm77 (13.09.2007 16:41:18) [78]
Тебе достаточно не входить в ветку, а вот мы может поговорим еще немного.
← →
Anatoly Podgoretsky © (2007-09-13 16:58) [84]> evvcom (13.09.2007 16:44:19) [79]
Да я просто знал!!!
Кто то сказал, что АП знает ответ, еще до того как задан вопрос.
← →
zdm77 (2007-09-13 16:59) [85]
> Anatoly Podgoretsky © (13.09.07 16:58) [83]
ну поговорить, значит поговорить.... задаешь один вопрос.....и столько интересного можно узнать еще :)
← →
zdm77 (2007-09-13 17:00) [86]
> Anatoly Podgoretsky © (13.09.07 16:58) [84]
> > evvcom (13.09.2007 16:44:19) [79]
>
> Да я просто знал!!!
> Кто то сказал, что АП знает ответ, еще до того как задан
> вопрос.
такого небыло.... было предубеждение, которое думал развеят под впечатлением советов окружающих (не Вас)
← →
Вася Правильный (2007-09-13 17:02) [87]
> АП знает ответ, еще до того как задан вопрос.
я тоже знаю
только спрашивают обычно фигню какую-то, причем регулярно и в пределах 5% известных ответов
← →
Sandman31 (2007-09-13 17:05) [88]Минусы использования БД:
1. Относительная сложность копирования настроек одного пользователя другому.
2. Необходимость использования дополнительной программы для визуальной оценки настроек пользователя, особенно в случае иерархичной структуры настроек.
3. Лишняя нагрузка на сервер БД/сервер приложений/сеть.
4. Если придется восстанавливать БД из backup, восстановятся и настройки пользователя.
5. Нарушение шаблона проектирования - данные предметной области не должны храниться вместе с данными интерфейса.
← →
clickmaker © (2007-09-13 17:07) [89]
> 5. Нарушение шаблона проектирования - данные предметной
> области не должны храниться вместе с данными интерфейса.
можно отдельную базу завести :)
← →
Вася Правильный (2007-09-13 17:07) [90]
> данные предметной области не должны храниться вместе с данными
> интерфейса.
не факт, что интерфейс не является предметом предметной области
например, в зависимости от функции пользователя в предметной области у него разного размера/цвета/положения окна, разные галки по умолчанию и т.п.
← →
vpbar © (2007-09-13 17:08) [91]>>Sandman31 (13.09.07 17:05) [88]
1. Относительно это.
2. Непонял о чем.
3. Мелочи.
4. 5. Дык ониж в разных таблицах (базах)
← →
vpbar © (2007-09-13 17:09) [92]О как мы - хором
← →
zdm77 (2007-09-13 17:13) [93]
>
> Sandman31 (13.09.07 17:05) [88]
Первые вразумительные аргументы. НО.
1. Зачем копирование настроек одному пользователю другому? ты имеешь ввиду типоризованность? Так можно как раз в той-же БД создать таблицу с должностями и при заведении нового делать копию должности с опред. настройками, плюс специфика данного юзера.
2. Доп. программа не потребуется, в модуле "Администрирование" например, можно красиво и грамотно контролить настройки пользователей (опять-же, это скорее плюс чем минус)
3. Нагрузка копеешная. Хотя это надо смотреть конкретно (могу счесть за аргумент)
4. Если бэкап постоянный(и инкриментится) , то опять-же это плюс
5. Готов принять на веру. Хотя все равно, плюсы перекрывают.
← →
zdm77 (2007-09-13 17:15) [94]
> Вася Правильный (13.09.07 17:02) [87]
>
> > АП знает ответ, еще до того как задан вопрос.
>
> я тоже знаю
> только спрашивают обычно фигню какую-то, причем регулярно
> и в пределах 5% известных ответов
ну 5% это не плохой в принципе результат
← →
euru © (2007-09-13 17:21) [95]
> Вася Правильный (13.09.07 17:07) [90]
Мониторы могут быть монохромными. Разрешение экрана на разных компьютерах может быть различным. Как это учтут настройки в БД?
← →
zdm77 (2007-09-13 17:23) [96]
> euru © (13.09.07 17:21) [95]
а как это учтет INI? При запуске проги читается настройка из реестра и вносится как параметр в БД
← →
Sandman31 (2007-09-13 17:29) [97]zdm77 (13.09.07 17:13) [93]
1. Всё можно. Но это дополнительные работы: время, деньги. Есть и плюс хранения в БД - можно указать, настройки какого пользователя копировать новому пользователю или шаблон, как Вы написали.
2. Согласен. Но это дополнительные работы: время, деньги. Если централизованное управление не нужно (не было в ТЗ), то минус.
3. Да, тут всё ситуативно. Cookies хранятся локально, а не на сайтах, например :)
Самое главное, о чем тут уже писали. Всё равно не обойтись без хранения пути к БД или серверу приложений. А иначе принцип Protected Variations нарушается.
← →
Prohodil Mimo © (2007-09-13 17:31) [98]Sandman31 (13.09.07 17:05) [88]
1. Это смотря как и что копировать, можно и спецэксперта написать по копированию, что бы удобнее было.
2. Зачем оценивать расположения окон, цвета и т.п.
3. Равносильно оптимизации кода, как кто-то из сдешних мастеров сказал: сейчас компы такие, что на оптимизацию действий ни кто не смотрит. Хотя мне кажется, что зря.
4. А если накроется система пользователя, то накроются и все его настройки.
5. ни кто не заставляет хранить всё в одной БД, хотя, если мне тут советовали не заморачиваться с хранением картинок и файлов в отдельной БД, а всё хранить в одной, то не вижу преступления в одной лишней табличке среди основных данных.
← →
Sandman31 (2007-09-13 17:32) [99]zdm77 (13.09.07 17:23) [96]
Вот Вы уже пришли к выводу, что настройки должны быть завязаны не только на пользователя, но и на компьютер, с которого зашел пользователь. То есть хранение в реестре или профиле может оказаться лучше.
← →
zdm77 (2007-09-13 17:33) [100]
> Sandman31 (13.09.07 17:32) [99]
Давай на ТЫ?
Приму как аргумент, привязку к компу. Хотя это и в БД можно тоже предусмотреть.
← →
Sandman31 (2007-09-13 17:34) [101]Prohodil Mimo © (13.09.07 17:31) [98]
2. Зачем оценивать расположения окон, цвета и т.п.
Дело не в цветах, а в экстренном поиске возможной причины ошибки, с которой столкнулся пользователь.
← →
Sandman31 (2007-09-13 17:36) [102]Prohodil Mimo © (13.09.07 17:31) [98]
5. ни кто не заставляет хранить всё в одной БД, хотя, если мне тут советовали не заморачиваться с хранением картинок и файлов в отдельной БД, а всё хранить в одной, то не вижу преступления в одной лишней табличке среди основных данных.
Почему в одной? Мы же будем затем нормализацию проводить, на типы параметров (строка, целое число, картинка) разбивать. В общем, точно получим еще одну БД, как предлагает clickmaker.
← →
vpbar © (2007-09-13 17:37) [103]Sandman31 (13.09.07 17:32) [99]
Кстати да. Передвинем на одной машине окошко Left=900. Зайдем в прогу с другого компа(вроде такая возможность была тут озвучена) с разрешением 800х600 и нет окошка :)
← →
Админ (2007-09-13 17:38) [104]euru © (13.09.07 17:21) [95]
Разрешение экрана на разных компьютерах может быть различным. Как это учтут настройки в БД?
А ведь точно! Спасибо.
Нужно будет это учесть...
← →
zdm77 (2007-09-13 17:39) [105]
> vpbar © (13.09.07 17:37) [103]
логично, тут либо как уже говорил выше изначально читать реестр с настройками и взависимости от этого делать смещения. Либо Position:=DesctopCentr форева
← →
vpbar © (2007-09-13 17:41) [106]zdm77 (13.09.07 17:39) [105]
Или сохранять не абсолютную позицию(размер) а относительную
← →
Админ (2007-09-13 17:42) [107]Админ (13.09.07 17:38) [104]
Хотя в MDI полоса прокрутки появится... а главную форму я не сохраняю, а Maximize`лю.
← →
zdm77 (2007-09-13 17:44) [108]кстати, тема интересная на счет разрешений. Мне пригнали широкоформатный монитор. Удобно, конечно, можно не скрывать objectinspecor слева и Tool|Palet справа..код нормально размещается. Но чисто человеческий фактор подводит, все выглядит не так как на мониторах 4:3
← →
euru © (2007-09-13 17:47) [109]А почему в основном рассматривается вариант "исключающее ИЛИ"?
По-моему, в зависимости от вида настроек логичнее было бы использовать оба варианта.
← →
zdm77 (2007-09-13 17:47) [110]
> Админ (13.09.07 17:42) [107]
Щас боюсь попасть опять в немилость к мастерам, но как-то задавал вопрос -Почему все против MDI (фильм для дураков, фильм для дураков - а мне нравится). Хоть и Борланд, типа, как просто для поддержки ранее разработанных проектов использует эту возможность и WORD тот-же, который примером MDI приводили, уже не MDI давно.... и похожая тема, ни кто конкретных контраргументов, кроме общих фраз не привел.
← →
Sandman31 (2007-09-13 17:48) [111]zdm77 (13.09.07 17:33) [100]
Если ты будешь привязывать к компу, то придется и программный учет компьютеров вести, а только ради настроек это вряд ли имеет смысл делать.
В общем, сам оцени все настройки. Даже в одной программе я одни настройки храню в БД (которые админ может захотеть изменить - например, максимальное число передаваемых за один раз объектов, найденных в БД по запросу пользователя), а другие локально.
← →
zdm77 (2007-09-13 17:51) [112]
> Sandman31 (13.09.07 17:48) [111]
Возможно ты прав. Прикину.
← →
Админ (2007-09-13 18:14) [113]zdm77 (13.09.07 17:47) [110]
> Админ (13.09.07 17:42) [107]
Щас боюсь попасть опять в немилость к мастерам, но как-то задавал вопрос -Почему все против MDI (фильм для дураков, фильм для дураков - а мне нравится). Хоть и Борланд, типа, как просто для поддержки ранее разработанных проектов использует эту возможность и WORD тот-же, который примером MDI приводили, уже не MDI давно.... и похожая тема, ни кто конкретных контраргументов, кроме общих фраз не привел.
Не все, я не против :)
И даже более того - с таскбаром аля 1С 7.7 намного удобнее чем SDI.
← →
zdm77 (2007-09-13 18:19) [114]
> Админ (13.09.07 18:14) [113]
Хорошо.... я не один.... это радует. Мне нравится писать все в общем стиле с определенными управляющими элементами. А если нужно вызывать формы, которые должны быть в модальном режиме, то это совсем и не сложно зделать.
← →
Anatoly Podgoretsky © (2007-09-13 18:55) [115]> Sandman31 (13.09.2007 17:05:28) [88]
1. INSERT INTO SELECT FROM
2. Иерархию просто делать с помощью реестра
3. железный, пусть работает, обычно настройки считываются один раз
4. относится и к другим методам
5. вот это серьезно
6. в базе надо хранить настройки пользователя по работе с этой базой, при том, только те, которые применимы только после подключения пользователя, остальным там не место.
← →
Anatoly Podgoretsky © (2007-09-13 18:57) [116]> zdm77 (13.09.2007 17:13:33) [93]
1. Это одно из самых вкусных вещей. Шаблоны, резкое уменьшение объема работы по вводу нового пользователя. Но тогда стоит подумать и о группах/ролях.
← →
Anatoly Podgoretsky © (2007-09-13 19:00) [117]> Prohodil Mimo (13.09.2007 17:31:38) [98]
2. Нужно, но делать это надо локально, через реестр, если он не перемещаемый.
← →
Anatoly Podgoretsky © (2007-09-13 19:02) [118]> zdm77 (13.09.2007 17:47:50) [110]
Нравится - используй.
← →
Anatoly Podgoretsky © (2007-09-13 19:03) [119]> Админ (13.09.2007 18:14:53) [113]
В MDI нет понятия таскбар
← →
evvcom © (2007-09-14 08:58) [120]
> Sandman31 (13.09.07 17:05) [88]
1. В чем сложность? В [115] уже показана простота, а вот с реестром и ini-файлами в личных каталогах это сделать будет уже не реально без геморроя.
2. Зачем доп.программа? Копируешь настройки и оцениваешь той же прогой.
← →
Petr V. Abramov © (2007-09-14 16:31) [121]> Дык вот, все равно склоняюсь к созданию в БД типа такого. таблицы.
правильно склоняешься. при переустновке винды, пересаживанию юзера за другую машину и пр. юзер свои настройки не потеряет
← →
euru © (2007-09-14 17:26) [122]
> Petr V. Abramov © (14.09.07 16:31) [121]
О каких настройках идёт речь?
← →
Petr V. Abramov © (2007-09-14 17:33) [123]> euru © (14.09.07 17:26) [122]
да мало ли разных галок в программах бывает :)
← →
Slym © (2007-09-17 06:41) [124]zdm77 (13.09.07 16:16) [58]
если путь в dfm датамодуля прописан, то накакого дебагера не надо... Restorator или иной дергальщик ресурсов поможет
← →
MsGuns © (2007-09-17 09:56) [125]Стесняюсь спросить..
а где хранить настройки на базу настроек на базу данных ?
В базе настроек на настройки ?
;)
← →
evvcom © (2007-09-17 10:57) [126]
> MsGuns © (17.09.07 09:56) [125]
Это в [9] описано
Страницы: 1 2 3 4 вся ветка
Форум: "Прочее";
Текущий архив: 2007.10.14;
Скачать: [xml.tar.bz2];
Память: 0.8 MB
Время: 0.057 c