我的任务是学习 Lotus Domino Designer - 不知道我前世做了什么，但它一定很糟糕...... - 并且想知道如何在数据库上进行查找以获取一些选择值。由于这些信息可能会在许多应用程序中使用，我希望它只在一个地方。
我收集我可以使用@DBColumn，但是如果该查找中的条目发生更改会发生什么？如果查找的唯一值是文本，那么关系就会被破坏，不是吗？有什么方法可以模仿关系查找的想法吗？
我假设我从错误的角度看待 Lotus 开发，因为这似乎是查找的真正限制。
我在互联网上没有找到任何像样的学习材料，所以希望能得到任何帮助。
塔
您可能希望将唯一 ID 与文本值一起存储在源数据库中（与您在 RDBMS 中所做的不同）。然后，仅将该 ID 存储在任何引用文档中，并使用计算显示字段来查找显示值。（这里有一个性能考虑 - 您可以“反规范化”数据并将 ID 和文本值存储在引用文档中，并执行一些异步工作以保持值同步 - 例如：使用运行的计划代理每晚或每周）。
如果 DB1 具有键值，而 DB2 具有将引用这些值的文档，那么在 DB2 中的表单中，您仍然需要使用 @DbColumn 来查找您的值列表。在 DB1 的查找视图中，将文本值和 ID 与第一列中的竖线分隔符 (textField + "|" + ID) 连接起来。这将告诉 Notes 仅存储 ID 值（管道后面是“别名”，并且将被存储）。
注意：我会避免使用 @DocumentUniqueID 作为这些值的唯一 ID，因为如果复制和粘贴文档，或者复制整个数据库等，文档唯一 ID 会发生变化。您可以在组合时计算字段以生成接近唯一 ID 的内容（几乎就像 sql 中的标识列）。
如果您需要关系属性，请寻找非 Notes 解决方案。使用文档 UNID 和更新代理可以获得一些关系行为，但这比使用适当的关系后端更难。
您在引用一段可能会更改的文本时遇到的具体问题可以在某种程度上通过在选择字段中使用别名来解决。如果对话框列表包含表单上的值...
Foo|id1
Bar|id2
...表单将显示Foo但后端文档将存储值id1 -（这是您将能够在标准视图中显示的内容 - 尽管xpages可以解决这个问题）。在某些情况下，使用@DocumentUniqueIDfor 别名可能是个好主意。
这取决于您在哪里使用数据。如果字段设置为计算以供显示，@DBLookup 或@DBColumn 将在 Lotus Notes 字段中工作。这样，当您打开表单等时，他们总是能获得最新的信息。
如果您这样做是为了将数据保存到文档中，那么当您需要刷新值时，您将不得不编写一些更新代码。
设计者的 Lotus Notes 帮助文件非常好，看一下。
SM
您可以使用键或别名来存储与查找值的关系，因此如果值本身发生更改，则连接仍然存在，因为别名是完整的。例如，如果您的查找值被存储为文档集合，我将让@DBColumn 检索文档 UNID|查找值对。在显示模式下，您可以使用@GetDocField 检索该值。如果查找值在不同的数据库中，那么您必须使用 @DBLookup 检索它们以进行显示，并构造一个以 UNID 或您决定使用的任何键为键的视图。这种技术的唯一缺点是您将无法在视图中显示字段值，因为实际值未存储在文档中，只是对它的引用。但是，使用 XPage
这很棘手，但使用 LEI，您还可以使用 Notes 将关系后端系统作为前端，还可以在查找中为您提供所需的动态关系。
希望这可以帮助！
查找的内容可以自由更改。仅当查找键更改时才会出现问题（就像在相同情况下的任何其他平台上一样）。您需要使用不会更改的密钥。人类可读的文本是一个优势，但如果您希望能够将关键描述从“部门”更改为“业务单位”并且仍然可以进行查找，则需要使用某种别名，这将大概被映射到您的文本描述并且仅在内部使用。@Unique 对此非常有用，如果这对您很重要，它会给出一个简短的密钥。@DocumentUniqueID 是最可靠的，但正如 Ed 指出的那样，如果您复制/粘贴或制作非副本副本，它将改变（必须改变 - 这是一个新文档）。不过，这很容易解决。创建一个 Computed-when-composed 字段（例如，称为“