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

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

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

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

Мы пошли по третьему пути, используем одно 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

<?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

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... Никак или всё-таки есть варианты?

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

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

@okupoko 0 / 0 / 0 Регистрация: 04.10.2007 Сообщений: 2,977
	11.07.2010, 15:34	3
	VladSh , что-то я не понял твоего речевого оборота про мультиайтемы. Колонка представления не может "принимать" больше 32К данных, что тут решает мультиайтемность? Сообщение от Darker Мы пошли по третьему пути, используем одно RT поле, в котором в виде XML хранятся данные об исполнителях Хороший вариант, для своих задач. Но не позволяет управлять доступом. Только для отображения/хранения инфы. Я бы сказал, что, если документ имеет конкретного исполнителя, т.е. может быть исполнен одним пользователем в один период времени, то документов необходимо столько, сколько пользователей. Т.к. в этом случае и защита от конфликтных исправлений будет сразу. Если док может быть исполнен одним из нескольких пользователей, тогда не надо их отображать в виде, достаточно дать каждому из них доступ - тут уже мультиполя надо использовать для нотес-имен, на случай, если их может быть больше 32К. А когда один из пользователей примется за исполнение, тогда приходим к варианту - один исполнитель - один док. 0

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

@okupoko 0 / 0 / 0 Регистрация: 04.10.2007 Сообщений: 2,977
	11.07.2010, 16:45	5
	Сообщение от ToxaRat что-то страшное вспоминается из прошлого, когда БР хранил всех исполнителей РКК в одном главном документе Уважаемый, данная проблема не имеет ничего общего конкретно с БР, это багофича Нотес-БД. Не надо сводить описанные автором проблемы к названиям конкретных продуктов, особенно, если эти названия не были указаны автором лично. 0

@VtodSh 1 / 1 / 0 Регистрация: 07.12.2009 Сообщений: 1,197
	11.07.2010, 19:19	7
	Сообщение от Akupaka что-то я не понял твоего речевого оборота про мультиайтемы. Колонка представления не может "принимать" больше 32К данных, что тут решает мультиайтемность? Ничего Да даже 32К смысла уже нет показывать. Только что доступы будут работать. Вьюха - только один из способов нахождения нужного документа, далеко не основной... Сообщение от Akupaka Если док может быть исполнен одним из нескольких пользователей, тогда не надо их отображать в виде, достаточно дать каждому из них доступ - тут уже мультиполя надо использовать для нотес-имен, на случай, если их может быть больше 32К. А когда один из пользователей примется за исполнение, тогда приходим к варианту - один исполнитель - один док. Или бить на доки по определённому количеству юзеров в айтеме, тогда всё будет ок. Сообщение от Akupaka Уважаемый, ... Не надо сводить описанные автором проблемы к названиям конкретных продуктов, особенно, если эти названия не были указаны автором лично. Чего-то ты сегодня излишне агрессивен 0

@okupoko 0 / 0 / 0 Регистрация: 04.10.2007 Сообщений: 2,977
	12.07.2010, 00:48	8
	Сообщение от VladSh Или бить на доки по определённому количеству юзеров в айтеме Но это не имеет смысла, часто. Если могут исполнить 10 пользователей, но только один реально будет этим заниматься, то нет смысла указывать возможных исполнителей. Сообщение от VladSh Чего-то ты сегодня излишне агрессивен Сообщение от VladSh излишне агрессивен не правда 0

@ToxoRot 0 / 0 / 0 Регистрация: 04.11.2007 Сообщений: 3,019
	12.07.2010, 14:18	9
	Darker Данные хранятся в след порядке а почему их просто не хранить в полях? 0

@VtodSh 1 / 1 / 0 Регистрация: 07.12.2009 Сообщений: 1,197
	12.07.2010, 14:59	10
	Сообщение от Akupaka Но это не имеет смысла, часто. Если могут исполнить 10 пользователей, но только один реально будет этим заниматься, то нет смысла указывать возможных исполнителей. Потому я "исполнителей" и взял в кавычки, т.к. это всего лишь частный случай. В других случаях это имеет смысл ;) А разделять модель данных "под каждый чих" не вижу смысла. 0

@Dorkyr 0 / 0 / 0 Регистрация: 12.01.2009 Сообщений: 246
	12.07.2010, 16:13	11
	ToxaRat Сообщение от Darker надо быть осторожным с изменением значений, дабы не получить рассинхронизации кол-ва элементов 0

	12.07.2010, 19:59

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

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

@okupoko 0 / 0 / 0 Регистрация: 04.10.2007 Сообщений: 2,977
	12.07.2010, 17:09	14
	Сообщение от VladSh А разделять модель данных "под каждый чих" не вижу смысла Из тебя мог бы получиться классный конструктор! (не знаю где и кем ты сейчас работаешь) Но вот смог ли бы ты побороть армию 2пых аналитиков, которые идут на поводу у маркетинга и пользователей, которые не знаю чего хотят и нагружают "разработчика" абы да лишь бы? 0

@VtodSh 1 / 1 / 0 Регистрация: 07.12.2009 Сообщений: 1,197
	12.07.2010, 18:42	15
	Сообщение от Akupaka Из тебя мог бы получиться классный конструктор! (не знаю где и кем ты сейчас работаешь) Собственно я им и работал когда-то 3 года А сейчас вообще в ед.экземпляре - и конструктор себе и разработчик))) Сообщение от Akupaka Но вот смог ли бы ты побороть армию 2пых аналитиков, которые идут на поводу у маркетинга и пользователей, которые не знаю чего хотят и нагружают "разработчика" абы да лишь бы? ;) В разных случаях бывает по разному)) Но здесь больше от руководства зависит.. если оно технически грамотно, понимает, что у Лотуса своя, очень узкая область (это у меня сейчас такое руководство), то все песни аналитиков большого значения не имеют. Хотя в начале работу пришлось провести немалую: чтобы руководство увидело область применения... а потом оно же мне дало задание прочитать аналитикам серию занятий )) , чтобы они чепухи не городили, т.е. формировали только те требования, которые вписывается в платформу. Ну и в общем случае так стараемся делать: данные забросили в СЭД, прогнали по маршруту, согласовали... + ещё отчёты и оповещалки, всё остальное выгружать в специальные системы, которые, если надо, возвращают результат работы в виде статуса и проч. Короче: если аналитики нашей организации, то это наша головная боль, как их успокоить))) а вот если заказчик захотел, тогда да... - вот тогда это борьба!..) 0

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

@okupoko 0 / 0 / 0 Регистрация: 04.10.2007 Сообщений: 2,977
	12.07.2010, 18:59	17
	Сообщение от VladSh Но здесь больше от руководства зависит.. если оно технически грамотно, понимает, что у Лотуса своя, очень узкая область Вооооооот ))) Но я ж не просто так упомянул про маркетинг Ну это, если ты не сам себе ПМ-конструктор-разработчик-тестер, а в какой-то софтверной конторе работаешь. Тогда нет границам глупости народной... Ты вообще молодец, не расслабляйся только, а то потом тяжело нагонять прежний ритм... (( Добавлено: Сообщение от Darker Размер документа будет зависеть от кол-ва исполнителей, есть ли оптимальный размер одного документа Notes? "Оптимальный" эта как? Есть ограничение на кол-во информации в саммари-полях, есть ограничение на размер данных всех саммари-полей документа вкупе. Не саммари-поля, такие как РТ, не влияют на ограничения. Сообщение от Darker Хранить данные в виде XML в одном RT поле? Да храни так, как будет оптимально для решения твоей задачи. Твой случай не тривиальный, не каждый тут так делал, уверен! )) 0

@Dorkyr 0 / 0 / 0 Регистрация: 12.01.2009 Сообщений: 246
	12.07.2010, 19:04	18
	Сообщение от Akupaka Не саммари-поля, такие как РТ, не влияют на ограничения. А на производительность? Не будет ли документ открываться(сохраняться) дольше? 0

@VtodSh 1 / 1 / 0 Регистрация: 07.12.2009 Сообщений: 1,197
	12.07.2010, 19:59	20
	Сообщение от Akupaka не расслабляйся только, а то потом тяжело нагонять прежний ритм... (( Спасибо!) Ещё учиться и учиться... (особенно учитывая "будущность" Лотуса... (( ) Ты как чувствовал... Возможно и придётся "нагонять прежний ритм", т.к. нестабильные пошли времена... Сообщение от Akupaka Да храни так, как будет оптимально для решения твоей задачи. Твой случай не тривиальный, не каждый тут так делал, уверен! )) Так, знаю, данные хранят те, кто в веб их передаёт. Или наоборот получает из чужих систем; так парсить их потом удобно.. Если не надо во вьюхе в категории отображать, и если не надо по юзерам из этих данных доступ закрывать, то, наверное, это самый простой и правильный способ.. Сообщение от Darker ToxaRat Ты имеешь ввиду, хранить массив Имен исполнителей в одном поле, телефоны в другом, кодировки в третьем, сроки исполнения в четвертом, и.т.д.? А если не дай бог, какое-то поле "поедет", т.е кол-во элементов, в нем будет отлично от остальных полей? Для структуры из мультиайтемов лучше всего делать кнопки с вызовом диалога редактирования строки. Так вот, если данные допускают незаполненное значение, то при Ok в диалоге в проверке на заполненность можно пихать в пустые поля прочерк или сразу а потом в HTML разворачивать... Добавлено: Akupaka Свернули на интересную тему... вопрос по ходу.. не в курсе, от чего тупит открытие дока, если атачи большие (70-100 метров)? Вроде ж, по идее, файл должен подгружаться не на загрузке, а при попытке его открытия? Когда несколько таких файлов, то открытие документа иногда затупляет, ну и сообщение "типа превышен таймаут"... я так понимаю, что где-то лимитировано время запроса к серверу? В общем хотелось бы чтобы не разносить атачи по докам и обойтись без html... Никак или всё-таки есть варианты? 0