Lotus Notes 中的@DBColumn
我的任务是学习 Lotus Domino Designer - 不确定我以前做了什么，但它一定很糟糕...... - 并且想知道如何在数据库上进行查找以获得一些选择值。由于此信息可能会在许多应用程序中使用，因此我希望它只出现在一个地方。
我想我可以使用@DBColumn，但是如果该查找中的条目发生变化会发生什么？如果查找的唯一值是文本，那么关系就会被破坏，不是吗？有什么方法可以模仿关系查找的想法吗？
我假设我从错误的角度看待 Lotus 开发，因为这似乎是查找的真正限制。
我在互联网上没有找到任何像样的学习材料，因此将不胜感激。
塔
I've been tasked with learning Lotus Domino Designer - not sure what I did in a previous life, but it must have been pretty bad... - and was wondering how to do a lookup on a database to get some values for selections. As this information could potentially be used in a lot of the applications, I'd prefer it only to be in the one place.
I gather I can use @DBColumn, but what happens if an entry in that lookup changes? If the unique value of the lookup is the text, then the relationship would be broken, wouldn't it? Is there any way of mimicing the idea of relational lookups?
I'm assuming I'm looking at Lotus development from the wrong angle, as this seems to be a real limitation of look ups.
I haven't found any decent learning material on the interwebs, so would appreciate any help.
Ta
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您可能希望将唯一 ID 与文本值一起存储在源数据库中（与您在 RDBMS 中所做的类似）。然后，仅将该 ID 存储在任何引用文档中，并使用计算显示字段来查找显示值。 （这里有一个性能考虑 - 您可以“反规范化”数据并将 ID 和文本值存储在引用文档中，并执行一些异步工作以保持值同步 - 例如：使用运行的预定代理每晚或每周）。
如果 DB1 有键值，而 DB2 有引用这些值的文档，那么在 DB2 的表单中，您仍然需要执行 @DbColumn 来查找值列表。在 DB1 的查找视图中，在第一列中使用管道分隔符 (textField + "|" + ID) 连接文本值和 ID。这将告诉 Notes 仅存储 ID 值（管道后面的是“别名”，也是将要存储的内容）。
注意：我会避免使用@DocumentUniqueID作为这些值的唯一ID，因为如果复制和粘贴文档，或者复制整个数据库等，文档唯一ID将会改变。您可以在Computed-when-composed 字段生成接近唯一 ID 的内容（几乎像 sql 中的标识列）。
You would want to store a unique ID along with the textual value in the source database (not unlike what you would do in an RDBMS). Then, only store that ID in any referencing documents, and use a computed-for-display field to lookup the display value. (There is a performance consideration here - and you could "de-normalize" the data and store the ID and text value in the referencing documents, and do some asynchronous work to keep the values in sync - eg: using a scheduled agent that runs every night or every week).
If DB1 has the key values and DB2 has the documents which will reference these values, then in the form in DB2, you would still do a @DbColumn to lookup your value list. In the lookup view in DB1, concat the text value and ID with a pipe separator (textField + "|" + ID) in the first column. That will tell Notes to store only the ID value (what follows the pipe is the "alias" and is what will be stored).
Note: I would avoid using @DocumentUniqueID as the unique ID for these values, as the Document Unique ID will change if the documents are copied and pasted, or the entire database is copied, etc. You can use the @unique formula function in a computed-when-composed field to generate something close to a unique ID (almost like an identity column in sql).
如果您需要关系属性，请寻找非 Notes 解决方案。使用文档 UNID 和更新代理可以获得一些关系行为，但这比使用适当的关系后端更困难。
您在引用一段可能会发生变化的文本时遇到的具体问题可以在某种程度上通过在选择字段中使用别名来解决。如果对话框列表包含表单上的值...
...表单将显示 Foo 但后端文档将存储值 id1 - （这是您将能够在标准视图中显示的内容 - 尽管 xpages 可以解决这个问题）。在某些情况下，使用
@DocumentUniqueID作为别名可能是个好主意。If you need relational properties, look for non-Notes solutions. It is possible to get some relational behavior using document UNIDs and update agents, but it will be harder than with a proper relational backend.
Your specific problem with referencing to a piece of text that might change can to some extent be resolved by using aliases in the choice fields. If a dialog list contains values on the form...
...the form will display Foo but the back-end document will store the value id1 - (and this is what you will be able to show in standard views - although xpages could solve that). Using the
@DocumentUniqueIDfor alias can be a good idea under some circumstances.这取决于您在何处使用数据。如果将字段设置为计算显示，则@DBLookup 或@DBColumn 将在Lotus Notes 字段中工作。这样，当您打开表单等时，他们总是会获得最新的信息。
如果您将数据保存到文档中，那么当您需要刷新值时，您将不得不编写一些更新代码。
Lotus Notes 设计器的帮助文件非常好，可以看一下。
SM
It depends on where your using the data. The @DBLookup or @DBColumn will work in Lotus Notes fields if the fields are set to be computed for display. That way they always get the most up to date information when you open the form etc.
If you make it so the data is saved on to the document then you will have to write some update code when you need to refresh the values.
The Lotus Notes help files for designer are pretty good, have a look at that.
SM
您可以使用键或别名来存储与查找值的关系，因此如果值本身发生更改，连接仍然存在，因为别名完好无损。例如，如果您的查找值存储为文档集合，我会让 @DBColumn 检索文档 UNID|查找值对。当处于显示模式时，您可以使用 @GetDocField 检索该值。如果查找值位于不同的数据库中，那么您必须使用 @DBLookup 检索它们以进行显示，并构造一个由 UNID 或您决定使用的任何键锁定的视图。此技术的唯一缺点是您将无法在视图中显示字段值，因为实际值未存储在文档中，而只是对其的引用。不过，使用 XPages，您可以将关系映射到动态数据表中，就像在真正的关系系统中一样。
这很棘手，但使用 LEI，您还可以使用 Notes 作为关系后端系统的前端，同时为您提供查找中所需的动态关系。
希望这有帮助！
You could use a key or alias to store the relationship to your lookup value so if the value itself changes, the connection remains because the alias is intact. For example, if your lookup values were being stored as a collection of documents, I'd have the @DBColumn retrieve Document UNID|lookup value pairs. When in display mode, you could then retrive the value using @GetDocField. If the lookup values are in a different database, then you'd have to retrieve them for display using @DBLookup and construct a view that is keyed off of the UNID or whatever key you decide to use.The only drawback to this technique is that you wouldn't be able to display the field value in views as the actual value isn't stored in the document, just a reference to it. Using XPages, though, you COULD map the relationship into a dynamic datatable just like you would in a truly relational system.
It's tricky, but using LEI, you could also use Notes to front-end a relational backend system, also giving you the dynamic relationship you desire in your lookups.
Hope this helps!
查找的内容可以自由改变。只有当查找键发生变化时才会出现问题（就像在相同情况下在任何其他平台上一样）。您需要使用不会改变的密钥。人类可读的文本是一个优势，但如果您希望能够将关键描述从“部门”更改为“业务单位”并且仍然可以进行查找，则需要使用某种别名，这将大概会映射到您的文本描述并且仅在内部使用。 @Unique 对此非常有用，并且提供了一个较短的密钥（如果这对您很重要）。 @DocumentUniqueID 是最可靠的，但正如 Ed 指出的那样，如果您复制/粘贴或制作非副本副本，它将会更改（必须更改 - 这是一个新文档）。不过，这很容易解决。使用公式“@DocumentUniqueID”在用于参考文档的表单上创建一个“组合时计算”字段（称为“LookupRef”）。这将在创建时捕获 ID，并且在复制/粘贴等时不会更改。使用它作为密钥。
The content of the lookup can change freely. A problem only arises (as it would on any other platform in the same circumstances) if the lookup key changes. You need to use a key that won't change. Human-readable text is an advantage, but if you want to be able to change your key description from, say, "Divisions" to "Business Units" and still have lookups work, you need to use an alias of some kind, which will presumably be mapped to your text description and only used internally. @Unique is pretty good for this, and gives a shortish key, if that is important to you. @DocumentUniqueID is most reliable, but as Ed pointed out, will change (must change - it's a new document) if you copy/paste or make a non-replica copy. This is easy to get around, though. Create a Computed-when-composed field (called, say, "LookupRef") on the form you are using for your reference document with the formula "@DocumentUniqueID". That will capture the ID at the time of creation, and it will not change on copy/paste etc. Use that as your key.