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

[nayke]

Добрый день,

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

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

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

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

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

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

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

 

[savl]

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

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

 

[NickProstoNick]

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

 

[nayke]

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

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

 

[savl]

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

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

 

[ToxaRat]

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

 

[divankin]

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

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

 

[nayke]

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

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

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

Добавлено:

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

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

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

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

 

[lmike]

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

 

[divankin]

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

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

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

 

[savl]

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

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

 

[ToxaRat]

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

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

минусы:
- поле с UNID переполнится когда их будет много
- нужно отслежимать чтобы не было флага SUMMARY

Добавлено:

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

это первое :huh:

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

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

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

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

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

 

[NickProstoNick]

минусы:
- поле с UNID переполнится когда их будет много
- нужно отслежимать чтобы не было флага SUMMARY

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

Добавлено:

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

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

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

 

[nayke]

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

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

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

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

Спасибо.

 

[VladSh]

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

Не совсем понятна суть карточки(A) и суть регламента(Б). Регламент(Б) - это справочная информация (может быть прицеплен к разным карточкам?) или уникальная для карточки(A)? Просто неясна необходимость связи 'многие ко многим'.

 

[ToxaRat]

Просто неясна необходимость связи 'многие ко многим'.

создай бухгалтерскую программку - там это вдоль и поперёк счета, оплаты, договора, подряды и т.д.

 

[VladSh]

создай бухгалтерскую программку - там это вдоль и поперёк счета, оплаты, договора, подряды и т.д.

Я понимаю, что "бухгалтерская программка" это лучшее и оптимальное для реализации на Лотусе, но пытаюсь чуть больше приблизиться к сути задачи, м.б. можно этого избежать (а м.б. и нет).

 

[ToxaRat]

Я понимаю, что "бухгалтерская программка" это лучшее и оптимальное для реализации на Лотусе, но пытаюсь чуть больше приблизиться к сути задачи, м.б. можно этого избежать (а м.б. и нет).

да, я сейчас подобное клепаю, вообще взял за моду разные типы документов хранить в разных базах и рисовать связи какие угодно

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

 

[lmike]

да, я сейчас подобное клепаю, вообще взял за моду разные типы документов хранить в разных базах и рисовать связи какие угодно

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

как бы лотус "не натянул"

 

[Anatoly]

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