To store the configuration of Notes applications, there are to obvious possibilities and a third, not so obvious one, combining the benefits of the other alternatives, in two variants:
First alternative: profile documents
For this method you create one or more forms, but no views. To create configuration documents you use @EditProfileDocument instead of @Compose. To access stored values use @GetProfileField or NotesDatabase.GetProfileDocument.
The main advantage of this approach is performance. Its very efficient to get the profile documents and they are cached in the memory of each client.
This is also this method's biggest disadvantage. When a profile documents gets change by another user, the current user sees the old values until closing and reopening the Notes application. Another disadvantage is its reliability: Sometimes the profile document gets empty (only in older versions of Notes?). This can happen - for example - if there is a replica of the database, where - for whatever reason - the profile document does not exist or is not visible to the current user. Then a new and empty one gets created (even if the user only wants to read this document or one of its fields). The next time, the database get replicated, this profile document is newer then the original one and therefore replaces it.
Second alternative: normal documents and views
In this case you create one or more forms and at least one view. You create the configuration documents using @Compost or with View - Create. To access the stored values, you use @DbColumn, @DbLookup, NotesView.GetAllDocumentsByKey or NotesView.GetDocumentByKey.
Advantages: The documents are more "visible". Changes are in effect immediately (except when using [Cache] in the @ formulas) and this solution is more reliable.
But you have to pay for this advantages: The performance is really bad (in comparison), since the necessary view look-ups take quite some time.
Third alternative: a combination
Lets try to combine the advantages of both alternatives without their disadvantages. There are at least two approaches:
Variant 1: data duplication
As in the second alternative, you create forms and views and you also create "normal" documents to store the configuration in a reliable manner. But additionally every time the "normal" document is stored (e. g. in the PostSave event), you create or update a profile document with the same values. To access the data, you use the profile document (@GetProfileField and NotesDatabase.GetProfileDocument). When the profile document gets "lost" somehow, you - or a user with the necessary rights - just has to re-save the "normal" configuration document in order to recreate the profile document. But you have to actively interact with the application and the disadvantage with the cached values remains.
Variant 2: Pointer to "normal" documents
Here, too, you use forms, views and "normal" documents to reliably store the configuration information. But differently from the former solution, you don't store the whole data in a profile document, but only the UNID (@DocumentUniqueID or NotesDocument.UniversalID) of the "normal" document. To access the values, you use a @GetProfileField or NotesDatabase.GetProfileDocument to get the UNID of the configuration document first, and then use it with @GetDocField or NotesDatabase.GetDocumentByUNID to get the document or field value itself.
This variant is nearly as fast as the first alternative, since no view look-up is necessary. But the configuration information is stored safer and more reliable in "normal" documents. Further on, changes of configuration values are taken into account immediately, because only the UNID is cached.
If the profile document gets "lost" somehow, you can simply add some code to do a view look-up and store the UNID in a new profile document for later use. This can occur automatically, thus you don't need to manually intervene.