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

[LuMee]

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

 

[Ogion7]

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

Сделай в форме ответа поле, в которое запиши информацию из родителя, при создании ответа

 

[LuMee]

Сделай в форме ответа поле, в которое запиши информацию из родителя, при создании ответа

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

 

[morpheus]

Для: LuMee
Условие выборки в представлении применима ТОЛЬКАО к документу, и усё... ни к профилю ни к респонсам никак, соответсвенно необзожимо в документе хранить ключи/фразы из респонсов

 

[Fossil Code]

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

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

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

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

 

[LuMee]

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

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

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

Проблема в том, что мне нужно отобрать лишь небольшую часть ответов, с которыми должно отобраться и того меньше родителей. Причем критерии отбора применяются именно к ответам. Вот если бы была в лотусе какая-нибудь формула типа @Parent (обратная по своей сути @AllChildren)...

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

Фолдер - идея хорошая, в свое время одной из первых пришла в мою голову, однако тут все жестоко упирается в производительность. Открываться такой фолдер будет достаточно часто и достаточно большим количеством народу сразу, так что обновление содержимого таких фолдеров заставит-таки сервер поперхнуться.

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

 

[Fossil Code]

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