• Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе

    «Анализ защищенности веб-приложений»

    🔥 Записаться бесплатно!

  • CTF с учебными материалами Codeby Games

    Обучение кибербезопасности в игровой форме. Более 200 заданий по Active Directory, OSINT, PWN, Веб, Стеганографии, Реверс-инжинирингу, Форензике и Криптографии. Школа CTF с бесплатными курсами по всем категориям.

Исполнители документа

  • Автор темы Darker
  • Дата начала
D

Darker

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

Мы пошли по третьему пути, используем одно RT поле, в котором в виде XML хранятся данные об исполнителях.

Кто подумывал над этим?
 

VladSh

начинающий
Lotus Team
11.12.2009
1 783
157
BIT
53
Отдельный документ, но "исполнителей", бывает, надо отображать в видах... потому в мультиайтемах. При переполнении (иногда было такое) - AppendItemValue.
 
A

Akupaka

VladSh , что-то я не понял твоего речевого оборота про мультиайтемы. Колонка представления не может "принимать" больше 32К данных, что тут решает мультиайтемность?

Мы пошли по третьему пути, используем одно RT поле, в котором в виде XML хранятся данные об исполнителях
Хороший вариант, для своих задач. Но не позволяет управлять доступом. Только для отображения/хранения инфы.

Я бы сказал, что, если документ имеет конкретного исполнителя, т.е. может быть исполнен одним пользователем в один период времени, то документов необходимо столько, сколько пользователей.
Т.к. в этом случае и защита от конфликтных исправлений будет сразу.

Если док может быть исполнен одним из нескольких пользователей, тогда не надо их отображать в виде, достаточно дать каждому из них доступ - тут уже мультиполя надо использовать для нотес-имен, на случай, если их может быть больше 32К. А когда один из пользователей примется за исполнение, тогда приходим к варианту - один исполнитель - один док.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
Darker
что-то страшное вспоминается из прошлого, когда БР хранил всех исполнителей РКК в одном главном документе, потом списки сбивались и т.д.
ну и естественно не удавалось вбить туда приличное количество типа группу "все руководители"
это ОНО? :)
 
A

Akupaka

что-то страшное вспоминается из прошлого, когда БР хранил всех исполнителей РКК в одном главном документе
Уважаемый, данная проблема не имеет ничего общего конкретно с БР, это багофича Нотес-БД.
Не надо сводить описанные автором проблемы к названиям конкретных продуктов, особенно, если эти названия не были указаны автором лично.
 
D

Darker

Данные хранятся в след порядке
Код:
<?xml version="1.0" encoding="UTF-16"?>
<root>
<doc id = "DictionaryDB^ADMI-7G7F6U">
<Field name = "form">EstablishedPost</Field>
<Field name = "ElementNameKZ">Казбек К. .</Field>
<Field name = "ElementNameRU">Казбек К. .</Field>
<Field name = "PostNameKZ">Null</Field>
<Field name = "PostNameRU">Председатель Правления АО</Field>
<Field name = "EmployeePhone">74-74-74</Field>
<Field name = "EmployeeLNAddress">CN=К К Казбек/O=AONIT</Field>
<Field name = "ExSummary">Null</Field>
<Field name = "ExDocumentTransport">Null</Field>
<Field name = "ExStartDate">Null</Field>
<Field name = "ExDate">Null</Field>
<Field name = "ExCompleteDate">Null</Field>
<Field name = "ExDocumentBlankNumber">Null</Field>
<Field name = "ExIsBadDocument">Null</Field>
<Field name = "ExIsNotAcceptedAP">Null</Field>
<Field name = "ExType">InnerExecutors</Field>
</doc>
...
итд
</root>
по-моему, списки не должны сбиваться в этом случае
 

VladSh

начинающий
Lotus Team
11.12.2009
1 783
157
BIT
53
что-то я не понял твоего речевого оборота про мультиайтемы. Колонка представления не может "принимать" больше 32К данных, что тут решает мультиайтемность?
Ничего :)
Да даже 32К смысла уже нет показывать. Только что доступы будут работать.
Вьюха - только один из способов нахождения нужного документа, далеко не основной...

Если док может быть исполнен одним из нескольких пользователей, тогда не надо их отображать в виде, достаточно дать каждому из них доступ - тут уже мультиполя надо использовать для нотес-имен, на случай, если их может быть больше 32К. А когда один из пользователей примется за исполнение, тогда приходим к варианту - один исполнитель - один док.
Или бить на доки по определённому количеству юзеров в айтеме, тогда всё будет ок.

Уважаемый, ...
Не надо сводить описанные автором проблемы к названиям конкретных продуктов, особенно, если эти названия не были указаны автором лично.
Чего-то ты сегодня излишне агрессивен :)
 
A

Akupaka

Или бить на доки по определённому количеству юзеров в айтеме
Но это не имеет смысла, часто. Если могут исполнить 10 пользователей, но только один реально будет этим заниматься, то нет смысла указывать возможных исполнителей.
Чего-то ты сегодня излишне агрессивен
излишне агрессивен
не правда :)
 

VladSh

начинающий
Lotus Team
11.12.2009
1 783
157
BIT
53
Но это не имеет смысла, часто. Если могут исполнить 10 пользователей, но только один реально будет этим заниматься, то нет смысла указывать возможных исполнителей.
Потому я "исполнителей" и взял в кавычки, т.к. это всего лишь частный случай. В других случаях это имеет смысл ;) А разделять модель данных "под каждый чих" не вижу смысла.
 
D

Darker

ToxaRat
Ты имеешь ввиду, хранить массив Имен исполнителей в одном поле, телефоны в другом, кодировки в третьем, сроки исполнения в четвертом, и.т.д.? А если не дай бог, какое-то поле "поедет", т.е кол-во элементов, в нем будет отлично от остальных полей?
 
A

Akupaka

А разделять модель данных "под каждый чих" не вижу смысла
Из тебя мог бы получиться классный конструктор! (*не знаю где и кем ты сейчас работаешь*)
Но вот смог ли бы ты побороть армию 2пых аналитиков, которые идут на поводу у маркетинга и пользователей, которые не знаю чего хотят и нагружают "разработчика" абы да лишь бы? :)
 

VladSh

начинающий
Lotus Team
11.12.2009
1 783
157
BIT
53
Из тебя мог бы получиться классный конструктор! (*не знаю где и кем ты сейчас работаешь*)
Собственно я им и работал когда-то 3 года :)
А сейчас вообще в ед.экземпляре - и конструктор себе и разработчик)))

Но вот смог ли бы ты побороть армию 2пых аналитиков, которые идут на поводу у маркетинга и пользователей, которые не знаю чего хотят и нагружают "разработчика" абы да лишь бы? ;)
В разных случаях бывает по разному)) Но здесь больше от руководства зависит.. если оно технически грамотно, понимает, что у Лотуса своя, очень узкая область (это у меня сейчас такое руководство), то все песни аналитиков большого значения не имеют.
Хотя в начале работу пришлось провести немалую: чтобы руководство увидело область применения... а потом оно же мне дало задание прочитать аналитикам серию занятий )) , чтобы они чепухи не городили, т.е. формировали только те требования, которые вписывается в платформу. Ну и в общем случае так стараемся делать: данные забросили в СЭД, прогнали по маршруту, согласовали... + ещё отчёты и оповещалки, всё остальное выгружать в специальные системы, которые, если надо, возвращают результат работы в виде статуса и проч.
Короче: если аналитики нашей организации, то это наша головная боль, как их успокоить))) а вот если заказчик захотел, тогда да... - вот тогда это борьба!..)
 
D

Darker

Мне нужен Ваш "субъективный вердикт"
Хранить данные в виде XML в одном RT поле?
Размер документа будет зависеть от кол-ва исполнителей, есть ли оптимальный размер одного документа Notes?
 
A

Akupaka

Но здесь больше от руководства зависит.. если оно технически грамотно, понимает, что у Лотуса своя, очень узкая область
Вооооооот )))
Но я ж не просто так упомянул про маркетинг :)
Ну это, если ты не сам себе ПМ-конструктор-разработчик-тестер, а в какой-то софтверной конторе работаешь.
Тогда нет границам глупости народной...
Ты вообще молодец, не расслабляйся только, а то потом тяжело нагонять прежний ритм... ((

Добавлено:
Размер документа будет зависеть от кол-ва исполнителей, есть ли оптимальный размер одного документа Notes?
"Оптимальный" эта как? Есть ограничение на кол-во информации в саммари-полях, есть ограничение на размер данных всех саммари-полей документа вкупе.
Не саммари-поля, такие как РТ, не влияют на ограничения.
Хранить данные в виде XML в одном RT поле?
Да храни так, как будет оптимально для решения твоей задачи. Твой случай не тривиальный, не каждый тут так делал, уверен! ))
 
A

Akupaka

Не будет ли документ открываться(сохраняться) дольше?
В общем-то будет, но это не особо заметно до 5-10 мбайт веса в локальной сети.
Можешь потестировать - вложения повкладывать, либо текста нагнать и засечь время сохранения Timer().
Код:
timerValue = Timer()
call doc.Save(...)
timerValue = Timer() - timerValue
Msgbox cstr(timerValue)
Кроме того, если РТ-поле скрыто на УИ, то его текст не влияет на скорость отображения, на сколько я помню.
 

VladSh

начинающий
Lotus Team
11.12.2009
1 783
157
BIT
53
не расслабляйся только, а то потом тяжело нагонять прежний ритм... ((
Спасибо!) Ещё учиться и учиться... (особенно учитывая "будущность" Лотуса... (( )
Ты как чувствовал... Возможно и придётся "нагонять прежний ритм", т.к. нестабильные пошли времена...

Да храни так, как будет оптимально для решения твоей задачи. Твой случай не тривиальный, не каждый тут так делал, уверен! ))
Так, знаю, данные хранят те, кто в веб их передаёт. Или наоборот получает из чужих систем; так парсить их потом удобно..

Если не надо во вьюхе в категории отображать, и если не надо по юзерам из этих данных доступ закрывать, то, наверное, это самый простой и правильный способ..

ToxaRat
Ты имеешь ввиду, хранить массив Имен исполнителей в одном поле, телефоны в другом, кодировки в третьем, сроки исполнения в четвертом, и.т.д.? А если не дай бог, какое-то поле "поедет", т.е кол-во элементов, в нем будет отлично от остальных полей?
Для структуры из мультиайтемов лучше всего делать кнопки с вызовом диалога редактирования строки. Так вот, если данные допускают незаполненное значение, то при Ok в диалоге в проверке на заполненность можно пихать в пустые поля прочерк или сразу а потом в HTML разворачивать...

Добавлено: Akupaka
Свернули на интересную тему... вопрос по ходу.. не в курсе, от чего тупит открытие дока, если атачи большие (70-100 метров)? Вроде ж, по идее, файл должен подгружаться не на загрузке, а при попытке его открытия? Когда несколько таких файлов, то открытие документа иногда затупляет, ну и сообщение "типа превышен таймаут"... я так понимаю, что где-то лимитировано время запроса к серверу?
В общем хотелось бы чтобы не разносить атачи по докам и обойтись без html... Никак или всё-таки есть варианты?
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!