У меня клиент пожелал в СЭДе не просто вести договора, а с графиками платежей и произведенными оплатами, возможностью рулисть коэффициентами пени по каждому договору, учетом банковских рабочих дней и т.д. и т.п.
Со всеми сопутствующими отчетами.
-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
Связь Многие Ко Многим
- Автор темы nayke
- Дата начала
-
- Теги
- links
Со всеми сопутствующими отчетами.
Задача такая встречается сплошь и рядом.
Банальный пример - карточка товара и список поставщиков.
У каждого поставщика есть несколько товаров которые он может поставить на склад компании,
У каждого товара есть несколько альтернативных вариантов кто может поставить данный товар.
Пользователь хочет знать кто может поставить данный товар - добавляет в карточке товара список поставщиков без формирования уникальных атрибутов.
Получается иерархическая связь невозможно, но хранить наличие связи необходимо.
Почему это задача для Lotus? Данная информация фигурирует в договорах, счетах, КП и т.д. и является частью документооборота компании.
Задача такая встречается сплошь и рядом.
Банальный пример - карточка товара и список поставщиков.
У каждого поставщика есть несколько товаров которые он может поставить на склад компании,
У каждого товара есть несколько альтернативных вариантов кто может поставить данный товар.
честно я так и не понял в чем трудность ?!
есть товар, есть поставщик, в карточке товара должны быть идентификаторы поставщиков, в карточке поставщика - идентификаторы поставляемых товаров, два вида: товары по поставщикам и поставщики по товарам, один как ембедед в одну карточку, другой в другую, т.е. в карточке товара будут видны все поставщики, в поставщике все поставляемые товары.. это как бы в лоб, а дальше уже думать как это оптимизировать, если оно вообще нужно..
Банальный пример - карточка товара и список поставщиков.
У каждого поставщика есть несколько товаров которые он может поставить на склад компании,
У каждого товара есть несколько альтернативных вариантов кто может поставить данный товар.
честно я так и не понял в чем трудность ?!
есть товар, есть поставщик, в карточке товара должны быть идентификаторы поставщиков, в карточке поставщика - идентификаторы поставляемых товаров, два вида: товары по поставщикам и поставщики по товарам, один как ембедед в одну карточку, другой в другую, т.е. в карточке товара будут видны все поставщики, в поставщике все поставляемые товары.. это как бы в лоб, а дальше уже думать как это оптимизировать, если оно вообще нужно..
А ты им в ответ ' сами хотели видеть даже те иски, к которым нет доступа, и чтобы они еще при этом помечались [нет доступа]' ;-)а потом начинается "помогите документ открывается долго"
а если нужен сводный отчёт по 3-м типам документов из разных баз?
руками перебираешь и выгружаешь в ексель?
Нормально все. Получить десяток документов по ключу из представления и вывести их линки...а потом начинается "помогите документ открывается долго"
Кроме того пользователь может в своих настройках отказаться от получения подобной информации.
Самый простой способ:
1. Принцип: в документах Товара ничего не сохраняется о поставщике, т.к. это справочная инфа.
2. При выборе Товара в Поставщике прописываем в документе Поставщика инфу о товаре, это можно сделать по разному:
Вариант а). 2 item'а: 1 - UNID'ы товаров и 1 - текстовое поле с краткой инфой для отображения пользователю; для перехода следующие способы:
- пользователь жмёт кнопку "Перейти к товару", по которому вываливается диалог с выбором этих же наименований, - выбор - открытие карточки товара;
- краткая инфа по товарам сразу отображается в RadioButton-поле (ограничение - EditMode, можно обойти подменой формы с запретом сохранения), - выбираем прямо в доке - клацаем на кнопке - открытие карточки товара.
Вариант б). 2 item'а: 1 - UNID'ы товаров и 1 - RT с краткой инфой-ссылкой для отображения пользователю; добавление ссылки в RT осуществляется при добавлении Товара под Поставщика, т.е. генерация RT при каждом открытии документа не нужна, на скорость открытия влиять не будет; обновление наименования товара в RT при его изменении, как вариант, производить с помощью перегенерации всего содержимого RT.
3. Для отображения Поставщиков в определённом Товаре во внедрённом виде используем item с UNID'ами Товаров в доках Поставщиков.
Достоинство вариантов: никаких лишних документов и окурков, относительная прозрачность системы.
Ещё рабочий способ с доками-ссылками, как описывал ToxaRat.
Достоинства этого способа уже описывали, вот недостатки:
1. Отдельная БД - более медленно (необходимо подключение к другой БД), трудности с организацией внедрённых видов из других БД.
2. Куча дополнительных документов - дополнительная нагрузка на сервер, а также менее надёжно - документ может быть удалён сервером (к примеру, образовался bad-сектор, или док был удалён по ошибке, возможно программно, что в сумме нередко), при таком способе этот случай очень трудно отловить, т.к. жёстких ссылок в основных доках нет, - вариант с UNID'ами покажет сбой при первом же обращении.
"руками" слово то какое, одна кнопочка дзынь и отчёт слепился сам а по скольки базам он растянут это уже забота программера
Ваша претензия к данной задаче отношения не имеет. Здесь в другой БД находятся документы-линки, которые ну никак не надо будет выгружать в Excel вместе с данными других баз. К тому же никаких проблем со сводными отчётами из разных баз не существует, есть даже бестолковая тема об этом.
Я думаю автора все-таки интересовал вопрос оптимизации, поэтому отчасти имеет.
Сам стараюсь системные базы - логгирование, связи, change логи и прочее. Добавлять только по необходимости.
По оптимизации - совмещаем достоинства, перечисленные Тохой, и недостатки отсюда.
"сводный отчёт по 3-м типам документов из разных баз" для данной задачи высосан из пальца.
я не согласен что это недостатки
1) отдельная база это всегда быстрее - нету левых документов для индекса вида, нету левых окурков
2) засеки разницу - при збое ты теряешь документ если писал всё в него, а тут при збое ты теряешь только связь
ко всему случаю збои образуются при неоднократном перезаписывании документа - а тут связь отдельный док и он лишь ЕДИНОЖДЫ создался
и пишешь ты в тот самый док УНИД другого или в связь, если конечный док был удалён и так и так будет ошибкаи - так что мы теряем?
ко всему прочему разрывая связь тебе нужно ИСПРАВИТЬ один из двух документов, а тут лишь удалить документ-связь
для создания СВЯЗИ существующие документы НЕ ИЗМЕНЯЮТСЯ только при использовании документа-связи, а это опять таки нагрузка на индексы видов, где твои рабочие доки наверняка в пару десятков видов светятся
ToxaRat
Вот это интересный разговор!
Скорость сравнивается в отображении документов во внедрённых видах из текущей БД и из другой. Из другой - скорость прорисовки доков во внедрённом виде будет дольше, это очевидно.
Если скорость сравнивается по "нету левых документов для индекса вида", то в любом случае нужно отстроить вид по UNID'ам, хоть в текущей БД, хоть в другой. Т.е. опять же нет никакого проседания по скорости.
Но для индексера/репликатора/компактора как раз будет труднее ввод 3-й сущности, которой в предложенных мной вариантах нет (сами документы являются и линками).
К тому же в документе-линке прописывается 2 UNID'а, в предложенных же мной вариантах - 1, т.е. при сбое с этой точки зрения вариант с документами-линками вдвое менее устойчив.
К тому же, как уже было выше, 3 сущности для служб сервера хуже чем 2.
Так что проседание по скорости и ресурсам сервера будет скорее в предлагаемом тобой решении. В моём половина перекладывается на клиента (формирование RT и переформирование которое нужно делать очень редко), а также нет дополнительной сущности (доп. БД и документы-линки).
Но это не относится к данной теме.
Вот это интересный разговор!
В предложенных мной вариантов нет необходимости в "левых документах" и "левых окурках".
Скорость сравнивается в отображении документов во внедрённых видах из текущей БД и из другой. Из другой - скорость прорисовки доков во внедрённом виде будет дольше, это очевидно.
Если скорость сравнивается по "нету левых документов для индекса вида", то в любом случае нужно отстроить вид по UNID'ам, хоть в текущей БД, хоть в другой. Т.е. опять же нет никакого проседания по скорости.
Но для индексера/репликатора/компактора как раз будет труднее ввод 3-й сущности, которой в предложенных мной вариантах нет (сами документы являются и линками).
"Потеряться" могут не только доки из БД со связями. В моём случае это 2 сущности, в твоём - 3. Вероятности, как известно перемножаются, т.е. вариант с 3-мя сущностями в плане устойчивости будет менее предпочтителен.
К тому же в документе-линке прописывается 2 UNID'а, в предложенных же мной вариантах - 1, т.е. при сбое с этой точки зрения вариант с документами-линками вдвое менее устойчив.
Это реальный недостаток предлагаемых мной вариантов. Но реальный для тех, у кого нет собственного транзакционного (для СЭД) механизма, иначе на это перестаёшь обращать внимание.
Про индексы было выше - вид по UNID'ам придётся отстраивать в обоих случаях. Но в твоём варианте работы индексеру будет больше, т.к. внедрённый вид, как я понимаю, ты отображаешь и в документе Производителя, и в документе Товара, в предложенных же мной вариантах только один внедрённый вид, а другой заменяется RT-полем со ссылками.
К тому же, как уже было выше, 3 сущности для служб сервера хуже чем 2.
Так что проседание по скорости и ресурсам сервера будет скорее в предлагаемом тобой решении. В моём половина перекладывается на клиента (формирование RT и переформирование которое нужно делать очень редко), а также нет дополнительной сущности (доп. БД и документы-линки).
Тоже не так. У меня в БД есть 1 вид для каждой формы документа (чтобы доки можно было найти по FT-поиску), содержащий все документы, т.н. "внутренний архив", а изо всех оперативных видов доки периодически уходят, облегчая работу индексера.
Но это не относится к данной теме.
VladSh
ты просто непрошибаем, не могу понять только почему
В твоём варианте если ты добавил/изменил/удалил "связь" UNID в поле документы будет следующая цепь действий:
1) сохранение документа
2) обновление этого документа во всех видах где он светится ранее и должен светиться - порядка 20 видов в среднем - нефиговая такая работа для индексера
3) обновление встроенного вида
4) обновление РТ поля "псевдо связь"
в документе-связь лишь один пункт:
1) обновление встроенного вида
чувствуешь разницу в 4 раза?
и облегчать работу индексера видов можно только одним способом - не изменяя документы тем самым не заставляя индексер работать вообще!
если ты убрал док из вида, ты не облегчил работу индексеру - наоборот заставил его пробежаться по ВСЕМ видам в базе на предмет "светить/несветить" измененный док
ты просто непрошибаем, не могу понять только почему
В твоём варианте если ты добавил/изменил/удалил "связь" UNID в поле документы будет следующая цепь действий:
1) сохранение документа
2) обновление этого документа во всех видах где он светится ранее и должен светиться - порядка 20 видов в среднем - нефиговая такая работа для индексера
3) обновление встроенного вида
4) обновление РТ поля "псевдо связь"
в документе-связь лишь один пункт:
1) обновление встроенного вида
чувствуешь разницу в 4 раза?
и облегчать работу индексера видов можно только одним способом - не изменяя документы тем самым не заставляя индексер работать вообще!
если ты убрал док из вида, ты не облегчил работу индексеру - наоборот заставил его пробежаться по ВСЕМ видам в базе на предмет "светить/несветить" измененный док
ToxaRat
У меня конечно не "20 видов в среднем", а 7-8, но логика в твоих словах имеется. Тогда по индексеру предлагаемый тобой вариант будет лучше.
Все остальные "за" и "против" обоих вариантов остаются в силе.
Убирание дока из вида делается 1 раз, после которого он не изменяется и не пользуется индексером. Т.е. прямой профит.
У меня конечно не "20 видов в среднем", а 7-8, но логика в твоих словах имеется. Тогда по индексеру предлагаемый тобой вариант будет лучше.
Все остальные "за" и "против" обоих вариантов остаются в силе.
Убирание дока из вида делается 1 раз, после которого он не изменяется и не пользуется индексером. Т.е. прямой профит.
ура прогресс
а теперь вторая часть твоего абзаца
убирая док из вида и не меняя его - действительно индексер его больше не трогает этот вид
и тут вылазит минус когда используется встроенный вид в той же самой базе - так как документ ты будешь менять всегда - в архив, еще какие-то действия на прямую никак не связанные со "связью" в любом случае заставят индексер обновить и встроенный вид тоже - чего никак не наблюдается если встроенный вид в отдельной базе
Добавлено: ну и в довесок, чтобы народ понимал масштаб трагедии
Допустип у вам мега правильная база в ней 7 видов и 10К документов
так вот когда вы поменяете 100 документов ваш диск "дёрнется" 7*100=700 раз!!!
при отдельном виде в отдельной базе диск будет дёргаться только когда связь удалена/создана - тоесть не весь док а конкретная функция документооборота - СВЯЗЬ
а это значит из 100 измененных документов связей было изменено всего 5 а значит диск дёрнется 5 раз
видим разницу между 700 раз и 5 раз - разница в 700 / 5 = В 140 РАЗ!
и так касается абсолютно всего, добавте деградацию базы в связи с увеличением документов, видов, окурвок и получите разницу еще на пару порядков
отсюда и попытка "натягивать" лотус на реляционную структуру - каждой отдельной функции отдельный вид и отдельная база
В свете болезненной чувствительности платформы к индексам видов, мы (команда-разработчиков) движемся в сторону отказа от вьюх.
Для быстрого поиска необходимых групп документов, в рамках данного топика - связанных документов, используем нативную связь родитель-респонз. В качестве родителя используется темповый документ (unid которого зашифорван, для быстрого доступа), в котором содержится "отображательная" часть реального документа. А респонзы содержат UNID-ы связанных темповых документов.
При открытии реального документа А в БД Связи ищется темповый документ родитель (поиск по DigestKey), получаются его респонзы (связи), быстрый перебор коллекции, отображение готовой HTML таблицы в форме.
Получается идея схожа, только вьюх вообще нет.
Для быстрого поиска необходимых групп документов, в рамках данного топика - связанных документов, используем нативную связь родитель-респонз. В качестве родителя используется темповый документ (unid которого зашифорван, для быстрого доступа), в котором содержится "отображательная" часть реального документа. А респонзы содержат UNID-ы связанных темповых документов.
При открытии реального документа А в БД Связи ищется темповый документ родитель (поиск по DigestKey), получаются его респонзы (связи), быстрый перебор коллекции, отображение готовой HTML таблицы в форме.
Получается идея схожа, только вьюх вообще нет.
Обучение наступательной кибербезопасности в игровой форме. Начать игру!