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