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

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

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

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

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

Связь Многие Ко Многим

N

nayke

Добрый день,

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

Есть прикладная карточка(A) для каждой такой карточки из множества выбираются документы регламента(Б).
Получается для каждой карточки А будет много карточек Б, и наоборот.

По сути оптимально хранить только наличие связи, но как оптимально сделать это в Lotus Notes.

Я дошел до 2 решений:

1. Для каждой карточки А плодим дочерние карточки Б с набором полей для embedded view.
Плюс - удобство обработки, визуализация через View.
Минус - большое количество ненужных доков.

2. Хранить линки выбранных карточек Б (например unid) в карточке А. При открытии динамически в RT поле формировать табличку с линками.
Плюс - не будет множества лишних документов.
Минус - задержки на открытии, и главное - не прогнозируемая верстка - т.е. при большом количестве документов Б, таблица будет линейно увеличиваться - без скроллинга, панели действий и прочих плюсов Embedded view.

Собственно - подскажите из своего опыта - как решались подобные вопросы.
Спасибо.
 

savl

Lotus Team
28.10.2011
2 591
309
BIT
138
На старой работе была такая фишка:
Основная идея связи была: двусторонние и односторонние линки, то есть первый способ. На открытии линка стояло событие и открывался сразу документ связи.
Так же в некоторых документах был реализован второй способ, но там было ограничение на количество ссылок.
Еще был вариант со вьюшкой из другой базы: в документы, которые прикреплены, вставлялся UNID главного документа, на сохранении главного. Почти первый способ, но без создания линков.
Сейчас, на новой работе, есть идея создать одну единую базу и создавать линки там и вьюшку тянуть оттуда: гибрид некий получается.

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

NickProstoNick

Статус как статус :)
Lotus Team
22.08.2008
1 851
27
BIT
0
Зачем плодить копии?
Почему в карточках просто не хранить юниды связанных документов и зачем таблица?
Встроенный вид и перехват открытия документа.
 
N

nayke

Зачем плодить копии?
Почему в карточках просто не хранить юниды связанных документов и зачем таблица?
Встроенный вид и перехват открытия документа.

На карточке А необходимо показывать какие регламенты к ней прикреплены.
Желателен переход к регламенту.
Как использовать встроенный вид без копий?
 

savl

Lotus Team
28.10.2011
2 591
309
BIT
138
Если документами-ссылками то никак, это верно, но и полной копии не надо.
Создается док, в котором полей 6-7:
UNID регламента, реплика, путь базы.
Номер регламента, название, автор и дата создания/утрвеждения.
Минимум нужной инфы.
Далее из вьюхи на событии открытия документа идет получение этого дока по служебным полям. Но таки да, документы будут плодиться, мелкие, но будут.

А если хранить UNID'ы то есть вариант такой еще:
Делаются поля (на несколько значений), в одних хранятся UNID и путь к базе / реплика. Оно скрыто.
В другом поле хранятся названия регламентов (это поле один большой Hot-spot).
Делается соответствие порядка, то есть UNID из первого поля соответствует регламенту из второго.
Далее при нажатии Hot-spot открывается диалоговое окно со список и выбирается нужный.
Если есть WinPopUP menu, то можно в него вставить и выбирать так.
При выборе регламента получаем номер элемента в списке, находим нужный UNID и путь, получаем необходимый док и открываем.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
только первый способ и только отдельная база для этих карточек-связей и только встроенный вид
 
D

divankin

В документе А поле с UNID всех связанных документов Б. В документе Б поле с UNID всех связанных документов А.
В документе А встроенная вьюха с Show Single Category = UNID документов Б.

Но это все хорошо работает, если по документу Б нужно показывать одно и то же для разных документов А.
Если в одном документе А нужно показать одни значения из документа Б, а в другом А другие значения из того же Б, то да, придется делать разные документы ;)
 
N

nayke

только первый способ и только отдельная база для этих карточек-связей и только встроенный вид

А в чем преимущество отдельной БД?
Получается, что карточка при открытии будет строить представление на документы из другой?

При этом я так понимаю что если у меня 5 функциональных баз, то лучше хранить все линки в одной-системной?

Добавлено:
В документе А поле с UNID всех связанных документов Б. В документе Б поле с UNID всех связанных документов А.
В документе А встроенная вьюха с Show Single Category = UNID документов Б.

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

Если я не ошибаюсь, то указав многозначное поле в single category, например
в карточке А
Links ="унид1"
"унид2"

вылезает ошибка что категория должна быть single string.
Или этот как то обходится?
Показывать для всех документов А одно и тоже.
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 927
608
BIT
150
может что-то помудрить с псевдо $REF в общих вьюшках (а не встроенных) и мульти вэлью
тогда по доком "родителем" будут казаться его "чайлды", но один чайлд м.б. у нескольких родителей
 
D

divankin

Если я не ошибаюсь, то указав многозначное поле в single category, например
в карточке А
Links ="унид1"
"унид2"

вылезает ошибка что категория должна быть single string.
Или этот как то обходится?
Показывать для всех документов А одно и тоже.
Ой, ошибся.
Во вьюхе категоризация идет UNID документа А, который хранится в документе Б. То есть каждый Б показывается сразу в нескольких категориях
А в Show Single Category - UNID документа А из документа А. То есть тут значение одно.
 

savl

Lotus Team
28.10.2011
2 591
309
BIT
138
А в чем преимущество отдельной БД?
Получается, что карточка при открытии будет строить представление на документы из другой?
При этом я так понимаю что если у меня 5 функциональных баз, то лучше хранить все линки в одной-системной?
Все линки хранятся отдельно в системной базе, в текущей базе нет копий, соответственно размер текущей базы меньше.
Но если там будет 3-4 млн документов-ссылок, то это уже будет тяжело. Впрочем, все надо сравнивать и проверять.
Одна общая вьюха из системной базы, так проще тиражировать механизм.
Чтобы не сильно тормозило при открытии документа, вьюху нужно поместить на отдельную вкладку таблицы на форме.
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
В документе А поле с UNID всех связанных документов Б. В документе Б поле с UNID всех связанных документов А.
В документе А встроенная вьюха с Show Single Category = UNID документов Б.

Но это все хорошо работает, если по документу Б нужно показывать одно и то же для разных документов А.
Если в одном документе А нужно показать одни значения из документа Б, а в другом А другие значения из того же Б, то да, придется делать разные документы ;)
минусы:
- поле с UNID переполнится когда их будет много
- нужно отслежимать чтобы не было флага SUMMARY

Добавлено:
Все линки хранятся отдельно в системной базе, в текущей базе нет копий, соответственно размер текущей базы меньше.
Но если там будет 3-4 млн документов-ссылок, то это уже будет тяжело. Впрочем, все надо сравнивать и проверять.
Одна общая вьюха из системной базы, так проще тиражировать механизм.
Чтобы не сильно тормозило при открытии документа, вьюху нужно поместить на отдельную вкладку таблицы на форме.
это первое :huh:

а второе в рабочей базе нету "окурков" что является важнее всего!

ну и третье - связи добавляются в режиме чтения - то есть исходные документы НЕ МЕНЯЮТСЯ

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

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

короче плюсов отдельной базы тут много ;)
 

NickProstoNick

Статус как статус :)
Lotus Team
22.08.2008
1 851
27
BIT
0
минусы:
- поле с UNID переполнится когда их будет много
- нужно отслежимать чтобы не было флага SUMMARY
Так это около 32 Кб данных... кажется. Это же как его переполнять надо?

Добавлено:
В документе А поле с UNID всех связанных документов Б. В документе Б поле с UNID всех связанных документов А.
В документе А встроенная вьюха с Show Single Category = UNID документов Б.

Но это все хорошо работает, если по документу Б нужно показывать одно и то же для разных документов А.
Если в одном документе А нужно показать одни значения из документа Б, а в другом А другие значения из того же Б, то да, придется делать разные документы ;)
Автор ни слова не сказал о том, что данные в документе Б как-то фильтруются в зависимости от документа А.
И думаю что этого и не должно быть. Иначе начнутся проблемы. Потому как пользователь захочет увидеть все содержимое документа.
Так что мультивельюз поля в А и Б самый компромисный вариан.. мне так кажется
 
N

nayke

Так это около 32 Кб данных... кажется. Это же как его переполнять надо?

Добавлено:
Автор ни слова не сказал о том, что данные в документе Б как-то фильтруются в зависимости от документа А.
И думаю что этого и не должно быть. Иначе начнутся проблемы. Потому как пользователь захочет увидеть все содержимое документа.
Так что мультивельюз поля в А и Б самый компромисный вариан.. мне так кажется


Действительно, думал что мультивалью в колонке вьюшки вернет значения через разделитель - странно с чего это взял.
А так решение вполне рабочее - вместо unid использовать прикладные ID.

Поля в карточках не связаны, т.е. важен факт связи карточек. Поэтому думаю при условии, что для карточки А будет 10-20 карточек Б, вполне рабочий вариант.

Спасибо.
 

VladSh

начинающий
Lotus Team
11.12.2009
1 783
157
BIT
52
Есть прикладная карточка(A) для каждой такой карточки из множества выбираются документы регламента(Б).
Не совсем понятна суть карточки(A) и суть регламента(Б). Регламент(Б) - это справочная информация (может быть прицеплен к разным карточкам?) или уникальная для карточки(A)? Просто неясна необходимость связи 'многие ко многим'.
 

VladSh

начинающий
Lotus Team
11.12.2009
1 783
157
BIT
52
создай бухгалтерскую программку - там это вдоль и поперёк счета, оплаты, договора, подряды и т.д.
Я понимаю, что "бухгалтерская программка" это лучшее и оптимальное для реализации на Лотусе, но пытаюсь чуть больше приблизиться к сути задачи, м.б. можно этого избежать (а м.б. и нет).
 

ToxaRat

Чёрный маг
Green Team
06.11.2007
3 332
42
BIT
0
Я понимаю, что "бухгалтерская программка" это лучшее и оптимальное для реализации на Лотусе, но пытаюсь чуть больше приблизиться к сути задачи, м.б. можно этого избежать (а м.б. и нет).
да, я сейчас подобное клепаю, вообще взял за моду разные типы документов хранить в разных базах и рисовать связи какие угодно

так сказать натягиваю лотус на реляционку :)
 

lmike

нет, пердело совершенство
Lotus Team
27.08.2008
7 927
608
BIT
150
да, я сейчас подобное клепаю, вообще взял за моду разные типы документов хранить в разных базах и рисовать связи какие угодно

так сказать натягиваю лотус на реляционку :)
как бы лотус "не натянул" ;)
 
A

Anatoly

У меня в доках хранятся UNIDы связанных документах.
При открытии какого-либо дока получаю колекцию доков, содержащих ссылку на данный, и
формирую в РТФ-поле список линков на них с описанием.
Например в базе договоров при открытии карточки договора получаю из базы юристов список линков на иски по данному договору.
 
Мы в соцсетях:

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