1. Набираем команду codeby webinar. Набираем команду для организации и проведения вебинаров. Подробнее ...

    Скрыть объявление
  2. Требуются разработчики и тестеры для проекта codebyOS. Требования для участия в проекте: Знание принципов работы ОС на базе Linux; Знание Bash; Крайне желательное знание CPP, Python, Lua; Навыки системного администрирования. Подробнее ...

    Скрыть объявление
  3. Получи 30.000 рублей. Для получения денег необходимо принять участие в конкурсе авторов codeby. С условиями и призами можно ознакомиться на этой странице ...

    Внимание! Регистрация авторов на конкурс закрыта.

    Скрыть объявление

Отбор во вью по полям ответов

Тема в разделе "Lotus - Программирование", создана пользователем LuMee, 7 фев 2007.

  1. LuMee

    LuMee Well-Known Member

    Репутация:
    0
    Регистрация:
    2 май 2006
    Сообщения:
    477
    Симпатии:
    0
    Можно ли составить формулу отбора во вью таким образом, чтобы отбирались документы-ответы, удовлетворяющие определенным условиям, а также все родительские документы для выбранных ответов?
    Или, как вариант, другой вопрос: можно ли сделать так, чтобы для ответов во вью отображать значения каких-то полей родителей? Здесь, понимаю, задача еще труднее... Лично мне ничего на ум, кроме @GetDocField(@ParentDocumentId; "SomeField"), не приходит, однако в столбце вью такое точно не заработает.
     
  2. Ogion7

    Ogion7 Гость

    Репутация:
    0
    Сделай в форме ответа поле, в которое запиши информацию из родителя, при создании ответа
     
  3. LuMee

    LuMee Well-Known Member

    Репутация:
    0
    Регистрация:
    2 май 2006
    Сообщения:
    477
    Симпатии:
    0
    Была такая мысль, но не очень хочется так поступать: поле текстовое и довольно немаленькое. И потом, итак избыточность БД чрезвычайно некислая получается...
     
  4. morpheus

    morpheus скриптописец

    Репутация:
    0
    Регистрация:
    7 авг 2006
    Сообщения:
    3.915
    Симпатии:
    1
    Для: LuMee
    Условие выборки в представлении применима ТОЛЬКАО к документу, и усё... ни к профилю ни к респонсам никак, соответсвенно необзожимо в документе хранить ключи/фразы из респонсов
     
  5. Fossil Code

    Fossil Code Гость

    Репутация:
    0
    Сисемасиськи боролся с таким положением, пока не пришел к следующей технологии: при создании ответных документов, существенные атрибуты родительского документа наследуются в скрытые или открытые read-only поля. Это дает возможность строить категоризованные виды, которые фактически отражают иерархию родитель-ответ, но при этом пользуются механизмом ключевых общих полей. С такими видами гораздо удобнее работать, чем с родительскими-ответными. Это решает Ваш первый вопрос и, частично, второй.

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

    Если же предложенное рассуждение для Вас неприемлемо, то всегда существует возможность вместо вида воспользоваться фолдером, а вместо формулы отбора -- скриптом, который этот фолдер наполнит линками в точности так, как Вы этого захотите.
     
  6. LuMee

    LuMee Well-Known Member

    Репутация:
    0
    Регистрация:
    2 май 2006
    Сообщения:
    477
    Симпатии:
    0
    Собственно, подобный подход я и использую, однако, у меня таких полей и так уже весьма и весьма немало. Результат - избыточность просто суровая.
    Так, моя система является преемником более старой системы, основанной на реляционной БД (FoxPro). Помимо всего прочего, в мою систему из этой старой переносятся данные. Так 12Мбайтная "старая" база превращается в почти 50 Мбайт лотуса... Так что ввод каждого дублирующего поля меня расстраивает :lol: Но, по ходу, иного пути нет.
    Проблема в том, что мне нужно отобрать лишь небольшую часть ответов, с которыми должно отобраться и того меньше родителей. Причем критерии отбора применяются именно к ответам. Вот если бы была в лотусе какая-нибудь формула типа @Parent (обратная по своей сути @AllChildren)...
    Фолдер - идея хорошая, в свое время одной из первых пришла в мою голову, однако тут все жестоко упирается в производительность. Открываться такой фолдер будет достаточно часто и достаточно большим количеством народу сразу, так что обновление содержимого таких фолдеров заставит-таки сервер поперхнуться.

    В общем, придется, видимо, вводить доп. атрибут и в очередной раз перекраивать базу (хорошо, хоть эта процедура в лотусе выполняется легко :))...
     
  7. Fossil Code

    Fossil Code Гость

    Репутация:
    0
    Есть еще одна технология, и однажды, когда серверы были еще маленькими, т.е. стояли на рабочих станциях, ее попробовал, остался доволен, но просто железо (диск и скорость) заставило отказаться. Суть в применении полнотекстового поиска, (который нынче стал гораздо удобнее). Фиксированные и диалоговоые запросы вешаются на кнопки в виде. Естественно, от факта сохранения необходимой ключевой информации в документах не уйдешь. Это для отображения, для первоначального ввода -- можно по старинке, родитель-ответ.
     
Загрузка...

Поделиться этой страницей