@DBColumn в Lotus Notes

Question

Мне было поручено изучить Lotus Domino Designer - не знаю, что я делал в предыдущей жизни, но, должно быть, это было очень плохо ... - и задавался вопросом, как сделать поиск на для получения некоторых значений для выбора. Поскольку эта информация потенциально может использоваться во многих приложениях, я бы предпочел, чтобы она была только в одном месте.

Я понимаю, что могу использовать @DBColumn, но что произойдет, если изменится запись в этом поиске? Если уникальным значением поиска является текст, тогда связь будет нарушена, не так ли? Есть ли способ подражать идее реляционных поисков?

Я предполагаю, что я смотрю на развитие Lotus с неправильного угла, поскольку это, по-видимому, является реальным ограничением поиска.

Я не нашел достойного учебного материала на сайтах interwebs, поэтому был бы признателен за любую помощь.

Ta

Answer 1

Если вам нужно реляционные свойства, искать решения, не являющиеся Notes. Можно получить некоторое реляционное поведение с использованием документов UNID и агентов обновления, но это будет сложнее, чем с надлежащим реляционным бэкэнд.

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

Foo|id1 
Bar|id2 

... форма будет отображать Foo но серверный документ будет хранить значение id1 - (и это то, что вы будете быть в состоянии показать в стандартных представлениях - хотя xpages мог решить это). Использование псевдонимов @DocumentUniqueID может быть хорошей идеей при некоторых обстоятельствах.

Answer 2

Это зависит от того, где вы используете данные. @DBLookup или @DBColumn будут работать в полях Lotus Notes, если поля установлены для отображения. Таким образом, они всегда получают самую свежую информацию при открытии формы и т. Д.

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

Файлы справки Lotus Notes для дизайнера довольно хороши, взгляните на это.

SM

Answer 3

Вы хотите сохранить уникальный идентификатор вместе с текстовым значением в исходной базе данных (в отличие от того, что вы делали бы в СУБД). Затем сохраните только этот идентификатор в любых ссылочных документах и ​​используйте поле вычисляемого для отображения для отображения отображаемого значения. (Здесь есть оценка производительности, и вы можете «де-нормализовать» данные и сохранить идентификатор и текстовое значение в ссылочных документах и ​​выполнить некоторую асинхронную работу, чтобы сохранить значения в синхронизации - например: использование запланированного агента, который запускает каждую ночь или каждую неделю).

Если DB1 имеет значения ключа, а DB2 имеет документы, которые будут ссылаться на эти значения, то в форме в DB2 вы все равно будете делать @DbColumn для поиска вашего списка значений. В представлении поиска в DB1, concat текстовое значение и идентификатор с разделителем каналов (textField + "|" + ID) в первом столбце. Это будет означать, что Notes сохраняет только значение идентификатора (то, что следует за трубой, является «псевдоним», и это то, что будет сохранено).

Примечание: Я бы избегал использования @DocumentUniqueID в качестве уникального идентификатора для этих значений, так как уникальный идентификатор документа будет изменяться, если документы будут скопированы и вставлены, или вся база данных будет скопирована и т. Д. Вы можете использовать @unique function function в поле computed-when-created, чтобы сгенерировать что-то близкое к уникальному ID (почти как столбец идентичности в sql).

Answer 4

Вы можете использовать ключ или псевдоним, чтобы сохранить связь с вашим значением поиска, поэтому, если само значение изменяется, соединение остается, поскольку псевдоним не поврежден. Например, если ваши значения поиска хранятся в виде набора документов, я бы получил @DBColumn, чтобы получить пары Параметр доступа к документам UNID | В режиме отображения вы можете извлечь значение с помощью @GetDocField. Если значения поиска находятся в другой базе данных, вам придется извлекать их для отображения с помощью @DBLookup и построить представление, которое вызывается с помощью UNID или любого другого ключа, который вы решите использовать. Единственным недостатком этого метода является то, что вы не сможете отображать значение поля в представлениях, так как фактическое значение не сохраняется в документе, а просто ссылка на него. Однако, используя XPages, вы МОЖЕТЕ сопоставить отношение в динамическом datatable, как и в действительно реляционной системе.

Это сложно, но с использованием LEI вы также можете использовать Notes для интерфейсной реляционной бэкэнд-системы, также предоставляя вам динамические отношения, которые вы желаете в своих поисках.

Надеюсь, это поможет!

Answer 5

Содержание поиска может свободно изменяться. Проблема только возникает (как и на любой другой платформе в тех же обстоятельствах), если ключ поиска изменяется. Вам нужно использовать ключ, который не изменится. Человеко-читаемый текст является преимуществом, но если вы хотите изменить свое ключевое описание, скажем, «Дивизионы» на «Бизнес-единицы» и все еще работать с поиском, вам нужно использовать псевдоним какого-либо типа, который будет предположительно, будет отображаться в ваше текстовое описание и использоваться только внутренне. @Unique довольно хорош для этого, и дает короткий ключ, если это важно для вас. @DocumentUniqueID является самым надежным, но, как заметил Эд, он изменится (должен измениться - это новый документ), если вы копируете/вставляете или делаете копию без копии. Однако это легко обойти. Создайте поле Computed-when-consist (называемое, скажем, «LookupRef») в форме, которую вы используете для своего ссылочного документа, с помощью формулы «@DocumentUniqueID». Это приведет к захвату идентификатора во время создания, и он не изменится при копировании/вставке и т. Д. Используйте это как свой ключ.