Войти
 
 
   
 
  
Новости Notes.ру Библиотека Биржа труда Вопрос - ответ Форум Регистрация Поиск О проекте
Разделы
О Notes
Советы
Шаблоны и примеры
Литература
Презентации
 
Всё о задаче AdminP. Часть вторая   Во второй части мы завершаем рассмотрение AdminP. В ней рассмотрены запросы междоменного администрирования и способы управления функциями AdminP с помощью настроек документа сервера, команд консоли сервера, файла Notes.ini и интервалов очистки базы данных. В этой статье предполагается, что вы опытный администратор Domino и прочитали первую часть
О Notes Читать статью
 
Всё о задаче AdminP. Proxy-действия в R5 и Domino 6   Приложение к статье об административном процессе
О Notes Читать статью
 
Всё о задаче AdminP. Часть первая   Перевод классической статьи 2003-его года о задаче административного процесса (AdminP). Очень полезна для понимания работы механизма этой задачи. В первой части статьи описаны компоненты задачи AdminP, как они работают, и как их использование помогает сделать работу администратора Domino проще. Задача AdminP (сакращённо от Administration Process, Административный процесс) работает с базой административных запросов (Administration Requests, admin4.nsf)
О Notes Читать статью
 


О Notes

Главная   Библиотека   О Notes

Рекомендации по проектированию представлений


Николай Норкин, CLP R5
Вятские Информационные Технологии
nickanor@mail.ru

Рекомендации по проектированию представлений
Надеюсь, читатель простит, если автор очередную попытку возвратиться к теме проектирования представлений, начнёт с изложения некоторой квинтэссенции материала в виде общих правил проектирования представлений

  • Представления служат для поиска и навигации к искомому документу. Статистические и вычислительные возможности представлений ограничены
  • Представления наиболее критичны в требованиях юзабилити. Пользователь должен быстро найти необходимую информацию. Вместе с тем, нельзя информационно перегружать представления
  • Представления – одна из наиболее ресурсоёмких частей базы Notes. При их проектировании следует учитывать объём индекса представления, частоту и скорость обновления индекса, время реакции на запрос пользователя
  • Представления могут играть служебную роль (использоваться для вычисления) или служить элементами пользовательского интерфейса. Рекомендуется не смешивать эти два вида представлений. Представления пользовательского интерфейса рекомендуется создавать в базе в избыточном количестве, при этом пользователь обычно использует 3-5 представлений (в зависимости от назначения базы), для всех пользователей следует создавать 15-20 представлений (активно используются 6-8 из них)
  • Одно из главных ограничений представления – отбор документов в представление производится на основании только той информации, которая содержится непосредственно в самом документе, строка документа в представлении может отображать данные, содержащиеся собственно в документе без корреляции с данными других документов. Подобным же образом представление может отображать данные, содержащиеся исключительно в самой базе Notes

Технология работы представлений
Представление – наиболее ресурсоёмкая часть “движка” базы данных. Это очень заметно при первом открытии представления. Время открытия представления значительно. Зато уже следующее открытие происходит моментально. Это связано с технологией работы представления, в основе которой – две ступени
Первый этап – вычисления, связанные с построением и поддержкой актуальности индекса представления, второй – вычисления, связанные с показом представления пользователю
Можно упомянуть ещё предварительный этап, связанный с включением свойства базы Optimize document table map. Эта таблица содержит список документов исходя из их формы (поля Form), что с одной стороны делает более эффективным отбор документов в представления, использующие в формуле отбора имя формы, с другой стороны, возникают трудности в поддержке представлений в приложениях, оперирующих сменой форм документов
Индекс представления содержит в себе задание порядка сортировки и группировки, результатов вычисления формул столбцов сортировки, группировки, а также результаты итогов и промежуточных итогов. Кроме того, здесь же сохраняется и информация о доступе пользователей к документам (данные полей типа READERS и AUTHORS)
Следовательно, на объём индекса представления оказывает сильное влияние задание группировки, вычисления итогов столбцов, организация доступа на уровне документа
Кроме того, задание альтернативной сортировки (сортировки по щелчку на заголовке столбца) заставляет строить и “альтернативный” индекс, увеличивая объём индекса в разы

Поддержка индекса на сервере осуществляется задачей Indexer, представленной в двух ипостасях: Update и UpdAll
Задача Update входит в список задач, запускаемых в момент старта сервера (переменная notes.ini ServerTasks) и работающих, пока работает сервер. Задача поддерживает актуальность индексов представлений и полнотекстовых индексов баз данных, отслеживая событие изменения документов. При этом изменение индекса представления происходит за какой-то гарантированный промежуток времени. Обработка документа заключается в вычислении формул столбцов документа, хранящихся в индексе, определении позиции документа относительно других документов в соответствии с заданными параметрами сортировки, группировки, вычислению итоговых результатов
Задача Updall запускается в соответствии с расписанием (переменная notes.ini ServerTasksAt<hour>) или вручную с консоли сервера и обрабатывает индексы представлений и полнотекстовые индексы баз в соответствии с параметрами запуска задачи. После выполнения задания задача выгружается

Второй этап. Вычисления при показе представления пользователю
Две задачи вычислений, решаемые при визуализации представления: актуализация индекса представления и ограничение доступа к документам, защищённым на просмотр данным пользователем
Первая задача решается путём форсированной обработки Indexer'ом (задачей Update) индекса представления по изменённым документам (ранее указывалось, что задача обрабатывает изменения в гарантированный период времени, но пользователь должен получить актуальные данные немедленно)
Более детального описания заслуживает механизм вычислений доступа к документам, ограниченным механизмом Notes на основе полей READERS. Программное обеспечение клиента Lotus Notes запрашивает сервер на получение данных представления. Сервер получает фрагмент индекса, отфильтровывает документы на основе информации о доступе и передаёт данные клиенту Notes. Клиент Notes отслеживает интерфейсную наполненность экрана представления (таким образом, чтобы данные представления заполняли весь экран и был ещё избыток данных на случай незначительной навигации в пределах представления – перемещения вверх-вниз в пределах нескольких позиций не требовали нового запроса к серверу). Если экран не заполнен до конца – следует запрос к серверу за новой порцией данных. Вычисления доступа могут привести к увеличению времени открытия/навигации по представлению для пользователей, имеющих существенные ограничения в доступе к документам в базе. Это следует учитывать при проектировании представлений в базах, содержащих большое количество документов

Временно-зависимые представления
В формулах отбора и формулах колонок не рекомендуется использовать временно-зависимые величины (функции @Now, @Today и т.п.). Вычисления при открытии подобных представлений, направленные на актуализацию информации, сведут на нет наличие индекса представления, что приведёт, с одной стороны, к задержке при открытии (навигации по представлению), с другой стороны – к постоянной загрузке задачи Update и нерациональному использованию ресурсов сервера
Рекомендуемые варианты визуализации временно-зависимой информации:
Наиболее предпочтителен – использование календарного представления
Второй вариант – отбор документов в папку. Документы отбираются в папку агентом (плюс – весь код сосредоточен в одном месте, минус – временная задержка для изменённых документов) либо код добавления/исключения из папки навешен на процедуру сохранения документов (плюсы и минусы – наоборот)
Третий вариант – использование вместо функции @Today преобразования @TextToTime(“Today”) или @TextToTime(“Сегодня”). Недостатки – языковая зависимость, но главный недостаток – нечувствительность к смене даты. Действительно, мало что заставит индексёр считать, что в 00:00 индекс потерял актуальность. В этом случае необходимо обеспечить перестроение индекса (Запуск задачи Updall по этому представлению)
Четвёртый вариант – выставить параметр обновления представления не автоматически, а с определённым периодом (от 1 часа до 24 часов). Недостаток: - отсутствие отслеживания изменений индекса (актуальность данных будет определяться заданным периодом)

Пользовательско-зависимые представления
Очень часто начинающие разработчики пытаются решить задачу показа документов конкретному пользователю, определяя в качестве формулы отбора документов в представление контекстно-зависимую функцию @UserName. Однако использование этой и подобных функций не приводит к нужному результату для общих (shared) представлений. Причина: индекс представления строится и поддерживается в контексте, когда результатом выполнения функции @Username будет имя разработчика представления, имя первого пользователя, открывшего представление, или имя сервера, на котором строится индекс
Решение задачи:
  • Задействование механизма ограничения доступа на основе READERS-полей, если цель отбора – показать пользователю документы, к которым он имеет доступ
  • Категоризация представления по имени пользователя и показ встроенного представления на основе Show single category с формулой @Username
  • Использование личных представлений (общих, становятся личными при первом обращении – shared, private on first use, SPOFU). В этом случае представление строится для конкретного пользователя, и использование функции @Username обосновано. Возникающие при этом проблемы: при хранении индекса представления на сервере база слишком “разбухает” (для каждого пользователя создаётся своё представление), выход – создание десктопных представлений (shared, desktop private on first use). Для внесения изменений в дизайн SPOFU-представлений использовать агента с функцией @UpdateViewDesign (Подобно агенту Обновление структуры папок в почтовой базе)

Сортировка представлений
Использование сортировки колонок в представлении несильно увеличивает объём индекса и скоростные параметры работы (скорость индексирования и реакцию на запрос пользователя – на последний параметр вообще не влияет). Интерфейсные же преимущества сортировки очевидны
Вместе с тем, использование альтернативной сортировки (по щелчку на заголовке колонки) в итоге выливается в построение точно такого же по объёму и скорости индексирования представления. Нетрудно посчитать, что наличие каждой дополнительной колонки с альтернативной сортировкой равнозначно по объёму индекса появлению дополнительного представления, и на первоначальное индексирование представления и поддержку индекса будет затрачено в два раза больше времени. И всё же для небольших баз (до 50 000 документов) подобные сортировки довольно юзабельны, но применять их нужно с большой осторожностью, контролируя объём представлений и работу задачи индексёра

Контроль объёма представлений
Ежедневно текущий объём представлений можно обнаружить в базе журнала сервера log.nsf в представлении Usage\by Size. К сожалению, для получения данных об изменении объёма представлений, нужно предпринять дополнительные шаги, не являющиеся стандартной функцией системы. Поскольку документы размера представлений изменяются ежедневно (по умолчанию, в 5 часов утра при выполнении задачи Activity Logging), нужно разработать функционал (агент), копирующий эти документы в архив

Категоризация представлений
Категоризация колонок организует интерфейс работы с представлениями, предоставляя пользователю дополнительные средства навигации. Однако, использование категорий должно быть обосновано и ограничиваться небольшим количеством уровней (для Notes-клиента – не больше двух, для web-клиентов – не больше одного). Категоризация эффективна, если при развёртывании категории организуется доступ к части информации примерно равнозначной одному экрану приложения (один – три экрана). Представьте сами, если после трёх-четырёх щелчков по вложенным категориям Вы увидите всего один документ (или вообще не получите доступ к документам). Каково будет Ваше разочарование, и насколько неюзабельно будет приложение!
Следует также обратить внимание на увеличение индекса представления и времени/вычислительных ресурсов на его построение и актуализацию при использовании категорий

Пустые категории
Использование категоризации вкупе с механизмом разграничения прав доступа к документу зачастую приводит к эффекту, когда пользователь, раскрыв очередную категорию не видит документов, которые в ней содержатся (категория пуста). Это не очень красиво, кроме того, в название категории попадает часть информации из непредназначенной для пользователя. Включение свойства представления Don't show empty categories устраняет этот эффект, но может сильно сказываться на время отклика на запрос пользователя. В действительности, серверу предстоит вычислить не только доступ к конкретному документу, но и определить, показывать или не показывать категорию (для вычисления видимости одной экранной строки может понадобиться прошерстить не одну сотню строк индекса)

Итоговые значения категорий и представления
Итоговые значения общих (shared) представлений вычисляются на этапе построения/актуализации индекса и передаются пользователю как они есть без учёта доступа к документам. Следовательно, любой пользователь, имеющий доступ к представлению, может видеть итоговую информацию. Доступ к таким представлениям следует ограничивать

Категоризация и альтернативная сортировка
Использование в одном представлении категорий и альтернативной сортировки неоправдано, так как при использовании сортировки теряются как сама категоризация, так и информация, содержащаяся в категоризированных колонках. Рекомендуется строить набор представлений следующим образом: одно представление без категорий с альтернативной сортировкой по наиболее важным параметрам (с учётом возможного объёма такого представления) и представления, категоризованные по одному из наиболее важных параметров каждое

Ограничение доступа к представлению
Данный уровень ограничения доступа считается чисто интерфейсным, так как не обеспечивает ограничение доступа к документам (пользователь всегда может построить другое представление, получив необходимый набор документов, если доступ к ним не ограничен полями типа READERS). Единственное разумное использование доступа к представлению – это представления с итоговыми значениями. Вместе с тем, использование ограничения доступа связано с риском потерять этот элемент дизайна при серверной репликации, замене или обновлении дизайна базы, если эти действия выполняются пользователем, не имеющим доступа к представлению в базе или шаблоне

Папки
В отличие от представлений, папки не имеют формулы отбора документов. Наполнение папок более гибко – оно может производиться пользователем вручную или быть запрограммировано в логике приложения. В частности, именно использованием папки можно обеспечить решение задачи отбора документов, не имеющих ответных документов (или имеющих всего один, не более двух ответных документов). В зависимости от требований логики приложения код наполнения папки может быть выполнен в агенте либо “размазан” по событиям сохранения и удаления документов

Отметки о прочтении/непрочтении документов
Отметки прочтения документов создают нагрузку на следующие ресурсы: дополнительный объём дискового пространства, необходимый для хранения информации об этом событии; и дополнительные вычисления при показе представления пользователю, вызывающие дополнительную задержку в реакции системы на действия пользователя по открытию представления или навигации по представлению. Учитывая ещё непредсказуемость поведения данного механизма в распределённых репликах баз данных, применение отметок следует ограничить единичными случаями

Материалы по теме:
Проектирование представлений >>>
Как отобразить документы, в полях которых указан текущий пользователь >>>
Динамический отбор документов в представления >>>
Как удалить из базы приватные представления, хранящиеся на сервере >>>
Как обновить дизайн приватизированных SPOFU-папок? >>>

Java-апплет: альтернатива встроенному представлению >>>
 
  Опубликовано — 06/12/2007 |    

Автор, 25.06.2007:
Замечание по поводу языковой зависимости конструкций вида @TextToTime("Today"). Эта зависимость наблюдалась в пятой версии Notes. По крайней мере, в клиенте R6.5.3 под Win эта функция ведёт себя правильно, и нет необходимости использовать конструкцию @TextToTime("Сегодня")

Автор, 23.06.2007:
Костя, привет! а как это будет работать в распределённой среде? не чревато тем, что сервер вовремя не среплицировавшись будет показывать неверную информацию. Всё-таки updall штатно и независимо. Или есть побочные эффекты (дефекты)?

Constantin, 22.06.2007:
К "Временно-зависимые представления". Коля, IMHO следовало помянуть 5-й вариант (в развитие 3-го): в ф-лах колонок и селекции пишутся конструкции типа @Date(@Now), которые ночным агентом заменяются на @Date([dd.mm.yy]). Таким образом, индексер будет "напрягаться" только раз в сутки (неделю/месяц) или после обновления дизайна из шаблона, в остальное время вьюшка ведет себя штатно PS: очевидно, что это только для R6+



Добавить комментарий
Имя * :
e-mail
Комментарий * :
Код подтверждения * :

Мероприятия
Пресс-релизы
Биржа труда
Последнее на форуме
 
А так же:
Как удалить профиль?
16.04.2016 00:08:51
Скопировать в буфер поле документа
24.05.2015 08:55:52
Импорт DXL-описания документов в Lotus Domino. Одноимённые поля
16.04.2015 16:49:58
 
© LOGOSPHERE.RU