@dblookup / @dbcolumn for views

Of course there would be a performance impact, as with many other design decisions, but this should be for the developer to consider when choosing to implement it.

Such an operation would come with limits or building/updating views would be much too costly. As venues go, (Notes)QueryResultsProcessor is a potential to deliver this. Actions like double clicking to open or Properties display would need design and careful thought but it's not infeasible.

Unlikely to do it exactly as proposed, but we're working on a different method that would allow what you're planning to do.

I t think driving need here is a Domino equivalent of JOINs.

Performance will surely depend on how its implemented and then used?

If as you say 30k documents result in 30k lookups, and it was built so that clients actually do the lookup when reading the view, then yes I can imagine performance would be bad.

However:-

 - If 30k documents only result in 50 - 100 actual database lookups (IDs -> Values) and the results are cached in memory during the view index update then performance would be better

 - If the lookups are performed by the server as part of the view index update/rebuild processes and the values stored in the view index then clients can (hopefully) just read the view contents as quickly as they do now

It soundss really performance intensive.  Imagine a 30k document view, doing 30k @DBLookups for one column just to load the view.

Yes, correct. Some information only need in the view for the user and not need to safe in the document.

This is very vague. So please elaborate.

I assume you like to use @dbcolumn and @dblookup inside a column formula of a view?