|
|
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
Здравствуйте ! Есть форма с большим количеством вкладок, на которых большое количество гридов и полей ввода. Форма - карточка сотрудника, описывающая все данные о сотруднике. Форма показывается различным пользователям. В зависимости от настроек пользователя ему могут быть доступны различные вкладки формы и поля для просмотра или доступны для редактирования. Данные о доступности той или иной вкладки/поля нужно хранить в базе Возможно настройки нужно хранить не для пользователя, а для группы или же общие настройки группы и индивидуальные настройки пользователя В каком виде хранить эти настройки ? Под каждую настройку отдельно поле таблицы, или же одно больше текстовое/бинарное поле в котором хранить настройки по типу Ini файла (Параметр=значение) или же например XML структуру Может есть готовые обёртки ? Или подобные статьи в которых описаны плюсы и минусы. Как это реализовано у вас ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 08:26 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
DimaBr, Придумать права для пользователей. Что бы не привязываться жестко к интерфейсу, и, вообще, сущностей поменьше. Например, как у нас: пользователю разрешено просматривать протокол или нет, разрешено редактировать протокол или нет. Дальше возле этого права строится вся обвязка, и интерфейсная и кодовая. Возможно вообще в нескольких интерфейсах. Права в любом удобном виде хранить в базе. Цеплять это всё либо непосредственно к пользователям (если их относительно немного) либо, по хорошему, делать группы пользователей, раздавать права группам, а пользователей вносит в группы, по мере необходимости. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 08:47 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
Привязывать доступ к элементам интерфейса, особенно к каждому полю-колонке-- заманчивая, но бесперспективная идея. В конечном итоге все эти настройки сами собой сведутся к небольшому количеству стандартных шаблонов/ролей, которые и будут назначаться пользователям. Тут все зависит от объемов: если приложение несложное, а сами потенциальные роли ограничиваются небольшим перечнем типа "заказы-финансы-отчеты", то можно прямо в коде захардкодить проверки (в основном, в главном меню-форме). Если что-то сложное, много разработчиков, разные системы и надо что-то универсальное -- можно все хранить в базе, внутри под капотом будут доступы к элементам форм и кастомным объектам, но все настройки и доступы будут идти через стандартные роли/группы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 09:04 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
Собственно вопрос о структуре хранения настроек: 1. Отдельные поля под каждый чих в настроечной таблице 2. Одно текстовое/блоб поле по типу Ini-файла 3. Поле XML типа или текстовое с хранением XML 4. Другой вариант ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 09:46 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
я обычно делаю объект TMySettings и прямо туда загружаю данные из JSON с помощью XSuperObject это удобнее чем XML. Если поля объекта поменяются, JSON тоже изменится. Да и объем в два раза меньше ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 09:52 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
Отдельный список (одна настройка -- одна запись). Это позволит потом строить довольно полезные отчеты по типу кто чем пользуется, что востребовано, а что нет, подсчитать количество реальных пользователей у каждого модуля. Если писать логи доступа (кто какой доступ запрашивает) -- то и отчеты об использовании приложения тоже можно собирать. В базе всё это занимает мало места по сравнению с остальными данными, и работает быстро -- даже если запросы к серверу будут идти каждый раз при открытии формы и/или по таймеру. Зато запросы легко делать -- не надо ковыряться в тех же xml/json данных. А эти отчеты в последствие пригодятся -- например, для службы безопасности, при исследовании инцидентов с доступом/порчей данных, сливов. Да и самим разработчиком -- видеть, что чаще всего используется, а что никому неинтересно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 09:56 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
Плюс легко можно делать массовые изменения -- например, когда добавляется новая фича и ее надо включить у всех, у кого есть доступ к другой фиче из той же темы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 09:57 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
DimaBr, У JEDI есть компоненты для однообразного хранения параметров в Ini|XML|DB, сам я правда их не смотрел, все руки не доходят ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 09:59 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
JaDiОтдельный список (одна настройка -- одна запись). Такого типа ? ПользовательПараметрЗначениеИвановДоступКРедактированиюФИОестьПетровДоступКРедактированиюФИОнетСидоровДоступКРедактированиюФИОпо вторникам ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 10:16 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
DimaBr, Почти. Иерархический справочник всех объектов, к которым можут быть доступ. Например, в виде структуры: модуль/приложение - раздел/форма - меню/кнопки/экшены/своё (или как удобнее хранить). Справочник ролей (тоже можно иерархический/папкам для удобного хранения, если их будет много) с настройками доступа под каждую роль -- тот самый список объектов, куда есть доступ (в виде ссылок на справочник выше). Справочник пользователей с привязкой к реальным сотрудникам из кадровой базы, доменным пользователям и т.п. сведения. В т.ч. список ролей, назначенных пользователю (ссылки на справочник ниже) -- та самая таблица из поста выше, только в виде ссылок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 10:26 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
Иерархическая система прав, хранится в базе данных в виде строк (одна строка - одно маленькое право). При соединении с базой данных эти права считываются (один раз) и в зависимости от их совокупности настраиваются интерфейсные элементы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 10:33 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
Были еще варианты в виде наследования ролей/доступов -- идея интересная, но усложняет некоторые запросы и логику настроек. Обычная техподдержка, которая потом всё это настраивает -- может не осилить и накосячить. На самом деле это один из главных вопросов -- кто всем этим будет заниматься и как ОРГАНИЗАЦИОННО всё это будет сделано в организации. Я бы от него и отталкивался. Потому что могут быть разные ситуации -- например, надо каждому сотруднику уникальный доступ настраиватт, или делать это по подразделениям (тоже нетривиальная задача -- проконтролировать, чтобы при переходе из одного отдела в другой -- у человека убрался старый доступ и он получил его к новым). Плюс может быть доступ К ДАННЫМ. Причем как к постоянным данным (список компаний и их базы), так и к динамическим (конкретным заказам, клиентам, направлениям). P.S. Был еще провальный опыт с доступом к объектам базы данных (через оракл). Но идея была оригинальной. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 10:38 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
Xml/json/ini - компактнее, первые два позволяют задать иерархию. Таблица Юзер-Имя опции-Значение опции - удобнее для изменения и статистики. Но плоская структура дает сложности в задании иерархических данных. Если настройки задаются админом, и юзер не может их менять (что-то вроде прав доступа) - то однозначно второй вариант. Если же это индивидуальные настройки, то особо без разницы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 11:20 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
JaDiНа самом деле это один из главных вопросов -- кто всем этим будет заниматься и как ОРГАНИЗАЦИОННО всё это будет сделано в организации. Я бы от него и отталкивался. Потому что могут быть разные ситуации -- например, надо каждому сотруднику уникальный доступ настраиватт, или делать это по подразделениям (тоже нетривиальная задача -- проконтролировать, чтобы при переходе из одного отдела в другой -- у человека убрался старый доступ и он получил его к новым). Плюс может быть доступ К ДАННЫМ. Причем как к постоянным данным (список компаний и их базы), так и к динамическим (конкретным заказам, клиентам, направлениям).Делал возможность копировать права с эталонного юзера на целевого с опцией объединения прав. Н-р у эталонного нет права редактировать ТипДокХХХ, а у пользователя есть. При копировании он это право потеряет, а при объединении нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 11:35 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
UserNameAppNameFormNameComponentNameVisibleEnabledВасяSuperBug.exeUglyFormTrueFalse Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 15:00 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
JaDiP.S. Был еще провальный опыт с доступом к объектам базы данных (через оракл). Но идея была оригинальной. О! Расскажи, пожалуйста, где провалилось? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 15:16 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
Мимопроходящий, как-то через name стрёмно лучше через например Help Context ну и Application/Form/Component я бы отдельной таблицей-справочником хранил древообразно. Также как и список пользователей и ролей - отдельными таблицами. А права доступа уже - их пересечения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 15:31 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
Glays, как практически отслеживать, что через три года после реализации функции её обновили, и теперь доступ к объектам 1,2,3 больше не нужен; к 4,5,6 наоборот стал нужен, а к 7,8,9 поменялся тип доступа ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 15:33 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
DimaBrВ каком виде хранить эти настройки ? Простая таблица в виде ключ/значение + доп. поля, например, если нужно разграничивать по id пользователя. Можно ещё добавить поле типа BLOB. Я так храню настройки cxGrid, dxLayoutControl - через TStream. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 15:39 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
DimaBrМожет есть готовые обёртки ? Не обёртки, но пример: Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 15:48 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
GlaysJaDiP.S. Был еще провальный опыт с доступом к объектам базы данных (через оракл). Но идея была оригинальной. О! Расскажи, пожалуйста, где провалилось? На одном промышленном предприятии -- там каких только подходов к организации доступа не применялось, в т.ч. и "оракловский". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 15:51 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
X11, думаю ТС имел в виду права доступа, а не настройки гридов и прочего... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 15:54 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
JaDi, зачод!!! спрашивали наверное все же - в контексте форума - какие именно проблемы вылезли в реализации/эксплуатации. Где в программировании была засада, а не в географии. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 15:57 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
Arioch, Из того, что сейчас вспоминается про оракловский доступ: - сервер загадился огромной кучей "пустых" пользователей/схем, которые стала мешать разработчикам чисто своим существованием -- и так было много схем под приложения/модули, а тут еще и "пустые" учетки в общую кучу подмешались; - очень сложные запросы по работе с доступом (вместо обычного sql к таблицам приходилось писать запросы к внутренностям оракла); - проблемы с доступом к объектам, когда по факту один модуль "тихо" использовал данные из других схем -- что вылилось к решениям вида "давай полный доступ ко всем объектам базы, чтобы уж наверняка"; - оракловская часть была пятым колесом, весь доступ все-равно "дублировался" в таблицах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 16:15 |
|
||
|
Хранения Настроек Пользователя
|
|||
|---|---|---|---|
|
#18+
DimaBrВ каком виде хранить эти настройки ? Под каждую настройку отдельно поле таблицы, или же одно больше текстовое/бинарное поле Одно большое текстовое/бинарное поле. Ибо во-первых, эти поля практически не используются в серверной бизнес-логике, а во-вторых, есть предмет постоянного расширения. Конкретный формат хранения не особо важен. Лично я предпочитаю stringlist типа Раздел.Подраздел.Параметр=Значение как наиболее удачный вариант, сочетающий читаемость, лёгкость автоматической обработки, лёгкость ручного редактирования и отсутствие опасности задеть или забыть какую-нибудь закрывающую скобку. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.02.2018, 16:25 |
|
||
|
|

start [/forum/topic.php?fid=58&msg=39607675&tid=2041191]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
165ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
| others: | 286ms |
| total: | 559ms |

| 0 / 0 |
