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

@Dorkyr · Регистрация: 12.01.2009

Студворк — интернет-сервис помощи студентам

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

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

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

@VtodSh · 11.07.2010, 14:20

Отдельный документ, но "исполнителей", бывает, надо отображать в видах... потому в мультиайтемах. При переполнении (иногда было такое) - AppendItemValue.

@okupoko · 11.07.2010, 15:34

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

Сообщение от Darker

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

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

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

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

@ToxoRot · 11.07.2010, 16:01

Darker
что-то страшное вспоминается из прошлого, когда БР хранил всех исполнителей РКК в одном главном документе, потом списки сбивались и т.д.
ну и естественно не удавалось вбить туда приличное количество типа группу "все руководители"
это ОНО?

@okupoko · 11.07.2010, 16:45

Сообщение от ToxaRat

что-то страшное вспоминается из прошлого, когда БР хранил всех исполнителей РКК в одном главном документе

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

@Dorkyr · 11.07.2010, 17:56

Данные хранятся в след порядке

LotusScript
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
<?xml version="1.0" encoding="UTF-16"?>
<root>
<doc id = "DictionaryDB^ADMI-7G7F6U">
<Field name = "form">EstablyshedPost</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>

по-моему, списки не должны сбиваться в этом случае

@VtodSh · 11.07.2010, 19:19

Сообщение от Akupaka

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

Ничего
Да даже 32К смысла уже нет показывать. Только что доступы будут работать.
Вьюха - только один из способов нахождения нужного документа, далеко не основной...

Сообщение от Akupaka

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

Или бить на доки по определённому количеству юзеров в айтеме, тогда всё будет ок.

Сообщение от Akupaka

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

Чего-то ты сегодня излишне агрессивен

@okupoko · 12.07.2010, 00:48

Сообщение от VladSh

Или бить на доки по определённому количеству юзеров в айтеме

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

Сообщение от VladSh

Чего-то ты сегодня излишне агрессивен

Сообщение от VladSh

излишне агрессивен

не правда

@ToxoRot · 12.07.2010, 14:18

Darker

Данные хранятся в след порядке

а почему их просто не хранить в полях?

@VtodSh · 12.07.2010, 14:59

Сообщение от Akupaka

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

Потому я "исполнителей" и взял в кавычки, т.к. это всего лишь частный случай. В других случаях это имеет смысл ;) А разделять модель данных "под каждый чих" не вижу смысла.

@Dorkyr · 12.07.2010, 16:13

ToxaRat

Сообщение от Darker

надо быть осторожным с изменением значений, дабы не получить рассинхронизации кол-ва элементов

@ToxoRot · 12.07.2010, 16:23

Darker
ниче не понял

@Dorkyr · 12.07.2010, 16:26

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

@okupoko · 12.07.2010, 17:09

Сообщение от VladSh

А разделять модель данных "под каждый чих" не вижу смысла

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

@VtodSh · 12.07.2010, 18:42

Сообщение от Akupaka

Из тебя мог бы получиться классный конструктор! (*не знаю где и кем ты сейчас работаешь*)

Собственно я им и работал когда-то 3 года
А сейчас вообще в ед.экземпляре - и конструктор себе и разработчик)))

Сообщение от Akupaka

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

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

@Dorkyr · 12.07.2010, 18:48

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

@okupoko · 12.07.2010, 18:59

Сообщение от VladSh

Но здесь больше от руководства зависит.. если оно технически грамотно, понимает, что у Лотуса своя, очень узкая область

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

Добавлено:

Сообщение от Darker

Размер документа будет зависеть от кол-ва исполнителей, есть ли оптимальный размер одного документа Notes?

"Оптимальный" эта как? Есть ограничение на кол-во информации в саммари-полях, есть ограничение на размер данных всех саммари-полей документа вкупе.
Не саммари-поля, такие как РТ, не влияют на ограничения.

Сообщение от Darker

Хранить данные в виде XML в одном RT поле?

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

@Dorkyr · 12.07.2010, 19:04

Сообщение от Akupaka

Не саммари-поля, такие как РТ, не влияют на ограничения.

А на производительность? Не будет ли документ открываться(сохраняться) дольше?

@okupoko · 12.07.2010, 19:18

Сообщение от Darker

Не будет ли документ открываться(сохраняться) дольше?

В общем-то будет, но это не особо заметно до 5-10 мбайт веса в локальной сети.
Можешь потестировать - вложения повкладывать, либо текста нагнать и засечь время сохранения Timer().

LotusScript
1
2
3
4
timerValue = Timer()
call doc.Save(...)
timerValue = Timer() - timerValue
Msgbox cstr(timerValue)

Кроме того, если РТ-поле скрыто на УИ, то его текст не влияет на скорость отображения, на сколько я помню.

@VtodSh · 12.07.2010, 19:59

Сообщение от Akupaka

не расслабляйся только, а то потом тяжело нагонять прежний ритм... ((

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

Сообщение от Akupaka

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

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

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

Сообщение от Darker

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

Для структуры из мультиайтемов лучше всего делать кнопки с вызовом диалога редактирования строки. Так вот, если данные допускают незаполненное значение, то при Ok в диалоге в проверке на заполненность можно пихать в пустые поля прочерк или сразу а потом в HTML разворачивать...

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

Новые блоги и статьи Все статьи Все блоги /
Музыка, написанная Искусственным Интеллектом volvo 04.12.2025 Всем привет. Некоторое время назад меня заинтересовало, что уже умеет ИИ в плане написания музыки для песен, и, собственно, исполнения этих самых песен. Стихов у нас много, уже вышли 4 книги, еще 3. . .	От async/await к виртуальным потокам в Python IndentationError 23.11.2025 Армин Ронахер поставил под сомнение async/ await. Создатель Flask заявляет: цветные функции - провал, виртуальные потоки - решение. Не threading-динозавры, а новое поколение лёгких потоков. Откат?. . .	Поиск "дружественных имён" СОМ портов Argus19 22.11.2025 Поиск "дружественных имён" СОМ портов На странице: https:/ / norseev. ru/ 2018/ 01/ 04/ comportlist_windows/ нашёл схожую тему. Там приведён код на С++, который показывает только имена СОМ портов, типа,. . .	Сколько Государство потратило денег на меня, обеспечивая инсулином. Programma_Boinc 20.11.2025 Сколько Государство потратило денег на меня, обеспечивая инсулином. Вот решила сделать интересный приблизительный подсчет, сколько государство потратило на меня денег на покупку инсулинов. . . .	Ломающие изменения в C#.NStar Alpha Etyuhibosecyu 20.11.2025 Уже можно не только тестировать, но и пользоваться C#. NStar - писать оконные приложения, содержащие надписи, кнопки, текстовые поля и даже изображения, например, моя игра "Три в ряд" написана на этом. . .
Мысли в слух kumehtar 18.11.2025 Кстати, совсем недавно имел разговор на тему медитаций с людьми. И обнаружил, что они вообще не понимают что такое медитация и зачем она нужна. Самые базовые вещи. Для них это - когда просто люди. . .	Создание Single Page Application на фреймах krapotkin 16.11.2025 Статья исключительно для начинающих. Подходы оригинальностью не блещут. В век Веб все очень привыкли к дизайну Single-Page-Application . Быстренько разберем подход "на фреймах". Мы делаем одну. . .	Фото: Daniel Greenwood kumehtar 13.11.2025	Расскажи мне о Мире, бродяга kumehtar 12.11.2025 — Расскажи мне о Мире, бродяга, Ты же видел моря и метели. Как сменялись короны и стяги, Как эпохи стрелою летели. - Этот мир — это крылья и горы, Снег и пламя, любовь и тревоги, И бескрайние. . .	PowerShell Snippets iNNOKENTIY21 11.11.2025 Модуль PowerShell 5. 1+ : Snippets. psm1 У меня модуль расположен в пользовательской папке модулей, по умолчанию: \Documents\WindowsPowerShell\Modules\Snippets\ А в самом низу файла-профиля. . .

@Dorkyr 0 / 0 / 0 Регистрация: 12.01.2009 Сообщений: 246

	Исполнители документа 11.07.2010, 14:15. Показов 23640. Ответов 20 Метки нет (Все метки) Хотелось бы узнать у форумчан, как у вас хранятся сведения об исполнителях? Создается ли у вас отдельный документ для каждого исполнителя или храните данные в многозначных полях? Первый способ удобен в плане управления данными (добавление, удаление, редактирование), но таких документов может набраться не одна сотня тысяч, да и вид, отображающий эти доки тоже будет "в шоке" Второй способ экономит память, освобождает нас от надобности бегать по респонсам, но надо быть осторожным с изменением значений, дабы не получить рассинхронизации кол-ва элементов Мы пошли по третьему пути, используем одно RT поле, в котором в виде XML хранятся данные об исполнителях. Кто подумывал над этим? 0

@VtodSh 1 / 1 / 0 Регистрация: 07.12.2009 Сообщений: 1,197
	11.07.2010, 14:20
	Отдельный документ, но "исполнителей", бывает, надо отображать в видах... потому в мультиайтемах. При переполнении (иногда было такое) - AppendItemValue. 0

@ToxoRot 0 / 0 / 0 Регистрация: 04.11.2007 Сообщений: 3,019
	11.07.2010, 16:01
	Darker что-то страшное вспоминается из прошлого, когда БР хранил всех исполнителей РКК в одном главном документе, потом списки сбивались и т.д. ну и естественно не удавалось вбить туда приличное количество типа группу "все руководители" это ОНО? 0

@ToxoRot 0 / 0 / 0 Регистрация: 04.11.2007 Сообщений: 3,019
	12.07.2010, 16:23
	Darker ниче не понял 0

@Dorkyr 0 / 0 / 0 Регистрация: 12.01.2009 Сообщений: 246
	12.07.2010, 16:26
	ToxaRat Ты имеешь ввиду, хранить массив Имен исполнителей в одном поле, телефоны в другом, кодировки в третьем, сроки исполнения в четвертом, и.т.д.? А если не дай бог, какое-то поле "поедет", т.е кол-во элементов, в нем будет отлично от остальных полей? 0

@Dorkyr 0 / 0 / 0 Регистрация: 12.01.2009 Сообщений: 246
	12.07.2010, 18:48
	Мне нужен Ваш "субъективный вердикт" Хранить данные в виде XML в одном RT поле? Размер документа будет зависеть от кол-ва исполнителей, есть ли оптимальный размер одного документа Notes? 0