Работа со справочниками

@tuMyy · Регистрация: 28.04.2006

Студворк — интернет-сервис помощи студентам

Предположим, что имеются 2 сущности:
1. "Документ" - просто некий документ в организации, имеющий определенный тип: приказ, служебная записка и т.п.
2. "Тип документа" - справочник, представляющий собственно тип, помимо названия характеризующийся еще рядом свойств.
В реляционной базе данных связь между ними описывалась бы просто: "Документ" имел бы поле, содержащее id соотв. "Типа..". Вопрос в том, как лучше это сделать в Lotus?
Пришло в голову:
1. в одном из полей "Документа" хранить название (строкой) соотв. "Типа..", потом по этой строке при необходимости находить тип и выбирать нужные свойства
2. завести у "Типа.." дополнительное поле - какой-нибудь номер, который записывать в поле "Документа"
3. в "Документе" хранить UNID соотв. "Типа..." (кстати, как правильно UNID записать в текстовое поле, выбрав из вью "Тип.."?)
4. сделать "Документ" ответом на "Тип..." - очень не хотелось бы, ибо возникнет ряд сложностей.
Очень хотелось бы услышать советы и коментарии профессионалов.

@tuMyy · 08.06.2006, 19:47

Сразу сходу еще один вопрос. Допустим, я решаю хранить некий код "Типа..." (какой бы то ни было). Соответственно, на форме "Документа" должно показываться название этого типа, в то время, как реально должен сохраняться именно код.
Название можно показывать с помощью Calculated-поля (перед сохранением подсовывать ему пустую строку, чтобы место не занимал), а поле с кодом "Типа..." сделать вычисляемым и скрытым. Вопрос в том, как организовать выбор. Идеальным вариантом было бы что-то вроде @PickList, только с возможностью выбора только одного значения. Причем выбираться должен документ, из которого я впоследствии вытащу нужное поле. Вот только все функции типа PickListа подразумевают возможноть выбора нескольких значений, что не годится...

@tuMyy · 09.06.2006, 20:09

Сразу сходу еще один вопрос. Допустим, я решаю хранить некий код "Типа..." (какой бы то ни было). Соответственно, на форме "Документа" должно показываться название этого типа, в то время, как реально должен сохраняться именно код.
Название можно показывать с помощью Calculated-поля (перед сохранением подсовывать ему пустую строку, чтобы место не занимал), а поле с кодом "Типа..." сделать вычисляемым и скрытым. Вопрос в том, как организовать выбор. Идеальным вариантом было бы что-то вроде @PickList, только с возможностью выбора только одного значения. Причем выбираться должен документ, из которого я впоследствии вытащу нужное поле. Вот только все функции типа PickListа подразумевают возможноть выбора нескольких значений, что не годится...

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

@somstomtym o shyrvomymko · 09.06.2006, 20:25

Сообщение от LuMee

Допустим, я решаю хранить некий код "Типа..." (какой бы то ни было). Соответственно, на форме "Документа" должно показываться название этого типа, в то время, как реально должен сохраняться именно код.

RTFM
CheckBox. C алиасами. Если значение/алиас статические - то просто защиваются в форму. Либо - вычисляются по формуле (выражение типа: FldTitle + "|" + FldAlias )

@tuMyy · 09.06.2006, 20:49

Сообщение от Constantin A Chervonenko

RTFM
CheckBox. C алиасами. Если значение/алиас статические - то просто защиваются в форму. Либо - вычисляются по формуле (выражение типа: FldTitle + "|" + FldAlias )

Пока сделал так: есть поле DocTypeName - название типа документа, поле DocTypeId - код типа документа (хранит соотв. UNID "Типа..."). Оба вычисляемые, второе - скрытое. Ну и хотспот для выбора типа (с помощью PickListCollection). UNID выбранного "Типа..." заносится в DocTypeId, а для DocTypeName в качестве значения повесил код:

Code
1
2
3
4
5
6
7
id:= DocTypeId;
@If(
id = "";
"не выбран";
 
@GetDocField(id; "DocumentTypeName") <-- выбираю поле "Типа...", содержащее его название
)

Перед сохранением документа (на Querysave) тупо убиваю DocTypeName с помощью NotesDocument.RemoveItem().

@tuMyy · 10.06.2006, 10:37

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

Code
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Sub Queryopen(Source As Notesuidocument, Mode As Integer, Isnewdoc As Variant, Continue As Variant)
Dim workSpace As New NotesUIWorkspace
Dim db As NotesDatabase
Dim allSampleForms As NotesView
Dim firstDoc As NotesDocument
 
If (IsNewDoc = True) Then
Set db = workSpace.CurrentDatabase.Database
Set allSampleForms = db.GetView("AllSampleForms")
Set firstDoc = allSampleForms.GetFirstDocument
Call Source.Document.ReplaceItem("$REF", firstDoc.UniversalID)
End If
 
Continue = True
End Sub

Была еще мысль сделать документ обычным, не ответом, а в ходе редактирования или по Querysave добавлять в него поле $REF - он ведь тогда будет считаться ответным, так?

@somstomtym o shyrvomymko · 10.06.2006, 12:53

Мудришь..
1.Удаление поля в QuerySave ничего не гарантирует. Формулы полей пересчитываются после QuerySave (RTFM!) и поле может возродиться. Делай временные поля CFD или удаляй их из формулы другого поля, расположенного ниже/правее
2.Не лезь с грязными ногами в $REF (для этого есть метод doc.MakeResponse pdoc RTFM!!), у тебя оно текстовое получается
3.PickList для выбора единственного значения из одного варианта - эт крутА. Нечеловеческий интерфейс

@tuMyy · 10.06.2006, 13:42

Сообщение от Constantin A Chervonenko

Мудришь..
1.Удаление поля в QuerySave ничего не гарантирует. Формулы полей пересчитываются после QuerySave (RTFM!) и поле может возродиться. Делай временные поля CFD или удаляй их из формулы другого поля, расположенного ниже/правее

Мудрю жестоко Про поле и Querysave уже сам задумался. Вот только насчет CFD - они разве не один раз вычисляются (при отображении документа)?

Сообщение от Constantin A Chervonenko

2.Не лезь с грязными ногами в $REF (для этого есть метод doc.MakeResponse pdoc RTFM!!), у тебя оно текстовое получается

Согласен, про MakeResponse подзабыл... Вот только применим ли данный метод к документу, который просто документ, а не ответ? И потом, все равно интересно, как правильно засовывать в поля документа UNIDы, чтобы они UNIDами оставались (вероятно, "Документ" будет участвовать в нескольких иерархиях). Просто достаточно в LotusScript заделать что вроде:

Code
1
doc.MyUnidField = otherDoc.UniversalID

или надо хитрее?

Сообщение от Constantin A Chervonenko

3.PickList для выбора единственного значения из одного варианта - эт крутА. Нечеловеческий интерфейс

А какими еще средствами можно выбрать какой-то документ из вью (один причем)? Мудрить с ComboBoxом и алиасами видимо будет непросто: не приходит в голову простая формула, которая выдернет набор значений вида "SomeDocField | UNID". Разве что с @DbColumn и циклами извращаться.. Или можно обойтись еще одной вью, со столбцом с такой формулой:

Code
1
DocTypeName + "|" + @Text(@DocumentUniqueID))

З.Ы. Жаль дома лотус не стоит, до вторника не попробую...

@somstomtym o shyrvomymko · 10.06.2006, 19:32

Сообщение от LuMee

Мудрю жестоко Про поле и Querysave уже сам задумался. Вот только насчет CFD - они разве не один раз вычисляются (при отображении документа)?

Не один (иногда это - проблема), а при каждом Recalculate и даже после Validation (см. соотв свойство поля)

Согласен, про MakeResponse подзабыл... Вот только применим ли данный метод к документу, который просто документ, а не ответ? И потом, все равно интересно, как правильно засовывать в поля документа UNIDы, чтобы они UNIDами оставались (вероятно, "Документ" будет участвовать в нескольких иерархиях). Просто достаточно в LotusScript заделать что вроде:

Code
1
doc.MyUnidField = otherDoc.UniversalID

или надо хитрее?

Смотря чем эти ссылки будут использоваться. Для формул/скриптов подойдет и текст (UniversalID - text). А вот что-б отобразить иконочкой на форме и иерархией во вьюхе - тип д.б. правильным. Правильный тип дает MakeResponse. Если надо несколько иерархий - перекладывай $REF в другой item (методом CopyItem, а не копированием значения! иначе опять будет "text")

А какими еще средствами можно выбрать какой-то документ из вью (один причем)? Мудрить с ComboBoxом и алиасами видимо будет непросто: не приходит в голову простая формула, которая выдернет набор значений вида "SomeDocField | UNID". Разве что с @DbColumn и циклами извращаться.. Или можно обойтись еще одной вью, со столбцом с такой формулой:

Code
1
DocTypeName + "|" + @Text(@DocumentUniqueID))

З.Ы. Жаль дома лотус не стоит, до вторника не попробую...

Можно и так

@tuMyy · 10.06.2006, 19:53

Сообщение от Constantin A Chervonenko

Смотря чем эти ссылки будут использоваться. Для формул/скриптов подойдет и текст (UniversalID - text). А вот что-б отобразить иконочкой на форме и иерархией во вьюхе - тип д.б. правильным. Правильный тип дает MakeResponse. Если надо несколько иерархий - перекладывай $REF в другой item (методом CopyItem, а не копированием значения! иначе опять будет "text")

Спасибо, буду пробовать

@somstomtym o shyrvomymko · 11.06.2006, 21:11

Сообщение от LuMee

Спасибо, буду пробовать

"Чё её пробовать! Её пить надо!"(с)
Делал такое неоднократно

@tuMyy · 11.06.2006, 23:47

Тут по ходу вопрос успел народиться (все не успевал дойти-задать). Если делать ComboBox, как было предложено в позапрошлом посте - UNID ведь в виде текста прийдет, так? Опять получается, что PickList сподручнее будет (пока что его оставил)... Хотя, конечно, можно по этому текстовому UNIDу вытаскивать документ, делаться его ответом, а потом в поле-ComboBox засовывать значение $REF методом CopyItem. Запутанно

@somstomtym o shyrvomymko · 12.06.2006, 00:11

Сообщение от LuMee

Если делать ComboBox, как было предложено в позапрошлом посте - UNID ведь в виде текста прийдет, так? Опять получается, что PickList сподручнее будет (пока что его оставил)... Хотя, конечно, можно по этому текстовому UNIDу вытаскивать документ, делаться его ответом, а потом в поле-ComboBox засовывать значение $REF методом CopyItem.

А из PickList - не текст?
Вообще - что-то не то делаешь. Чувствуются СУБДшные привычки. А Domino-е они вредны. В Домине нет ссылочной целостности; в Домине типична избыточность; Домине противопоказана (как правило) нормализация. Так что пиши в док-т значение, а не ссылку на словарный документ.
Нет, есть, конечно исключительные случаи... Впрочем, ты о своей задаче не докладывал

@tuMyy · 12.06.2006, 00:20

Сообщение от Constantin A Chervonenko

А из PickList - не текст?
Вообще - что-то не то делаешь. Чувствуются СУБДшные привычки. А Domino-е они вредны. В Домине нет ссылочной целостности; в Домине типична избыточность; Домине противопоказана (как правило) нормализация. Так что пиши в док-т значение, а не ссылку на словарный документ.
Нет, есть, конечно исключительные случаи... Впрочем, ты о своей задаче не докладывал

PickListCollection имелся ввиду Он возвращает коллекцию (из одного в моем случае документа), которую и пользую.
Насчет СУБДшных привычек - это да, всю жизнь с ними возился, а тут вдруг за Лотусом оказался. Собссно, потому топик и завел - было интересно, как в принципе такие вещи правильно делать.
От словарного документа ("Тип документа") отказываться неудобно имхо, т.к. помимо собственно названия он хранит еще ряд параметров, описывающих, что можно делать с документом данного типа.

@somstomtym o shyrvomymko · 12.06.2006, 10:56

Сообщение от LuMee

От словарного документа ("Тип документа") отказываться неудобно имхо, т.к. помимо собственно названия он хранит еще ряд параметров, описывающих, что можно делать с документом данного типа.

Никто отказываться и не заставляет. Но поскольку в Домине нет и транзакции (и не может быть! В действительно распределенной среде, под которую заточена Домина, она невозможна), нет никакой гарантии, что по ссылке ты найдешь тот документ, который ожидаешь (или вообще что-то найдешь). Поэтому (нарушая 2ю нормальную форму) после выбора позиции в словаре в док-т пишем не ссылку, а значения из словаря. Или, если очень хочется, то и другое

@tuMyy · 12.06.2006, 11:19

Сообщение от Constantin A Chervonenko

Никто отказываться и не заставляет. Но поскольку в Домине нет и транзакции (и не может быть! В действительно распределенной среде, под которую заточена Домина, она невозможна), нет никакой гарантии, что по ссылке ты найдешь тот документ, который ожидаешь (или вообще что-то найдешь). Поэтому (нарушая 2ю нормальную форму) после выбора позиции в словаре в док-т пишем не ссылку, а значения из словаря. Или, если очень хочется, то и другое

Как я отмечал, "Тип документа" определяет допустимые для "Документа" действия. Т.е., в зависимости от соотв. значений полей "Типа.." будут доступны или недоступны определенные действия над документом, а значит будут скрываться или показываться соотв. кнопки/хотспоты/actionы. Значения этих полей тоже следует вынести в "Документ", или можно вытаскивать из "Типа..." на лету? Просто хочется избежать большой избыточности ("Типов..." всего несколько штук, а "Документов" - многие тысячи).
И такой вопрос: нет ли где вообще литературы, описывающей правильные и неправильные подходы к проектированию баз данных в Лотус? А то, чувствую, реляционные привычки будут сильно сбивать с курса.

@somstomtym o shyrvomymko · 12.06.2006, 15:45

Сообщение от LuMee

..в зависимости от соотв. значений полей "Типа.." будут доступны или недоступны определенные действия над документом, а значит будут скрываться или показываться соотв. кнопки/хотспоты/actionы. Значения этих полей тоже следует вынести в "Документ", или можно вытаскивать из "Типа..." на лету? Просто хочется избежать большой избыточности ("Типов..." всего несколько штук, а "Документов" - многие тысячи).

Какая избыточность? У меня в таких местах 1(2) multivalue поле со всем деревом разбора. Штук 10 ключей тебе хватит? А это по размеру немногим отличается от UNIDa (32 символа)

И такой вопрос: нет ли где вообще литературы, описывающей правильные и неправильные подходы к проектированию баз данных в Лотус? А то, чувствую, реляционные привычки будут сильно сбивать с курса.

нЭту... Здравый смысл и опыт. В твоем случае определись: как должны себя вести старые документы после правки справочника? По старому или по новому?

@tuMyy · 12.06.2006, 18:56

Сообщение от Constantin A Chervonenko

У меня в таких местах 1(2) multivalue поле со всем деревом разбора. Штук 10 ключей тебе хватит? А это по размеру немногим отличается от UNIDa (32 символа)

Ммм, не совсем понял про дерево разбора...

Сообщение от Constantin A Chervonenko

В твоем случае определись: как должны себя вести старые документы после правки справочника? По старому или по новому?

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

Новые блоги и статьи Все статьи Все блоги /
Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Символьное дифференцирование igorrr37 13.02.2026 / * Программа принимает математическое выражение в виде строки и выдаёт его производную в виде строки и вычисляет значение производной при заданном х Логарифм записывается как: (x-2)log(x^2+2) -. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .	И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.
«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL3_image 8Observer8 10.02.2026 Содержание блога Библиотека SDL3_image содержит инструменты для расширенной работы с изображениями. Пошагово создадим проект для загрузки изображения формата PNG с альфа-каналом (с прозрачным. . .

@tuMyy 0 / 0 / 0 Регистрация: 28.04.2006 Сообщений: 225

	Работа со справочниками 08.06.2006, 14:13. Показов 30605. Ответов 17 Метки нет (Все метки) Предположим, что имеются 2 сущности: 1. "Документ" - просто некий документ в организации, имеющий определенный тип: приказ, служебная записка и т.п. 2. "Тип документа" - справочник, представляющий собственно тип, помимо названия характеризующийся еще рядом свойств. В реляционной базе данных связь между ними описывалась бы просто: "Документ" имел бы поле, содержащее id соотв. "Типа..". Вопрос в том, как лучше это сделать в Lotus? Пришло в голову: 1. в одном из полей "Документа" хранить название (строкой) соотв. "Типа..", потом по этой строке при необходимости находить тип и выбирать нужные свойства 2. завести у "Типа.." дополнительное поле - какой-нибудь номер, который записывать в поле "Документа" 3. в "Документе" хранить UNID соотв. "Типа..." (кстати, как правильно UNID записать в текстовое поле, выбрав из вью "Тип.."?) 4. сделать "Документ" ответом на "Тип..." - очень не хотелось бы, ибо возникнет ряд сложностей. Очень хотелось бы услышать советы и коментарии профессионалов. 0

@tuMyy 0 / 0 / 0 Регистрация: 28.04.2006 Сообщений: 225
	08.06.2006, 19:47
	Сразу сходу еще один вопрос. Допустим, я решаю хранить некий код "Типа..." (какой бы то ни было). Соответственно, на форме "Документа" должно показываться название этого типа, в то время, как реально должен сохраняться именно код. Название можно показывать с помощью Calculated-поля (перед сохранением подсовывать ему пустую строку, чтобы место не занимал), а поле с кодом "Типа..." сделать вычисляемым и скрытым. Вопрос в том, как организовать выбор. Идеальным вариантом было бы что-то вроде @PickList, только с возможностью выбора только одного значения. Причем выбираться должен документ, из которого я впоследствии вытащу нужное поле. Вот только все функции типа PickListа подразумевают возможноть выбора нескольких значений, что не годится... 0

@somstomtym o shyrvomymko 0 / 0 / 0 Регистрация: 26.05.2006 Сообщений: 1,313
	10.06.2006, 12:53
	Мудришь.. 1.Удаление поля в QuerySave ничего не гарантирует. Формулы полей пересчитываются после QuerySave (RTFM!) и поле может возродиться. Делай временные поля CFD или удаляй их из формулы другого поля, расположенного ниже/правее 2.Не лезь с грязными ногами в $REF (для этого есть метод doc.MakeResponse pdoc RTFM!!), у тебя оно текстовое получается 3.PickList для выбора единственного значения из одного варианта - эт крутА. Нечеловеческий интерфейс 0

@tuMyy 0 / 0 / 0 Регистрация: 28.04.2006 Сообщений: 225
	11.06.2006, 23:47
	Тут по ходу вопрос успел народиться (все не успевал дойти-задать). Если делать ComboBox, как было предложено в позапрошлом посте - UNID ведь в виде текста прийдет, так? Опять получается, что PickList сподручнее будет (пока что его оставил)... Хотя, конечно, можно по этому текстовому UNIDу вытаскивать документ, делаться его ответом, а потом в поле-ComboBox засовывать значение $REF методом CopyItem. Запутанно 0