Design Applications Based on Data Integrity Issues
The Notes/Domino database architecture is not relational; rather, it is an object store. What this means is that unlike a relational database, where redundancy is minimized through normalization and linked tables, redundancy is not only common, but it is often necessary in your Notes/Domino applications. That being said, your goal should be to minimize redundancy as much as possible because it leads to wasted storage and obsolete data.
In a relational database, it is common to normalize data and store it in separate tables, which can be dynamically linked. Notes/Domino, however, doesn't provide the same level of capability in this area. For example, you build a customer relationship management application that includes company documents and contact documents. The contacts are children of the company document and need to inherit certain key pieces of information from the company if they are to display properly in the views. For example, if the contact document does not store the company name value, the document does not display properly in views based on company name. Although this value could be looked up dynamically in a form through the use of @DbLookup or the GetDocumentByKey method of NotesView in LotusScript, it must reside in the document to be displayed in views. After the value has been inherited into the child document, that value is not refreshed automatically. So if the company name changes, all the documents for that company will contain obsolete information. The only remedy to this is to create an agent that updates the company name field in the contact documents if the name is changed.
In a relational database, the company name is not likely to be stored with the contact; rather, the contact record is probably linked to the company record through a common key. If the company name changes, as in the earlier example, users automatically see the new information because of the dynamic link and the lack of redundancy. As stated earlier, in some cases, redundancy is required to make the application function correctly. However, you should plan on keeping redundancy to a bare minimum in your application.
Documents can easily be copied (or cut) and pasted into the same database or into another database, both manually (through the Notes client interface) and programmatically. For example, you could use @Command([EditCopy]) and @Command([EditPaste]) in the Formula language or the Copy and Paste methods of NotesUIDocument or the CopyToDatabase method of NotesDocument Classes.
Although copying documents is quite easy, it is important to understand the implications of doing so. When a Notes document is copied and pasted, several things happen. First and foremost, the document is assigned a new Universal ID (UNID) and a new NoteID. Second, the document's Created, Modified, Added, Modified (In This File), and Accessed dates are all changed to reflect the time and date the document was pasted. Finally, if the document is being pasted into a view, the QueryPaste and the PostPaste events of the NotesUIView object (of the currently open view) are fired, enabling you to write code to handle the pasting of documents.
After the document has been pasted into the database, the document acts like any other document in the database, including replicating from one replica copy of the database to another. The only exception to this is if the document contains Authors or Readers fields that preclude accessing and/or replicating the document. It is also worth noting here that when you copy a document and its children (responses), the original response hierarchy is maintained.
Two functions especially useful when considering data integrity issues and when working with Universal IDs (UNIDs) of documents are the @GetDocField and @SetDocField functions. They are useful because they allow you to read and modify field values for documents that are not currently open. Both of these functions can only be used to modify documents that are located in the current database.
The @GetDocField function returns a value of a specified field for a specified document. The syntax of this function is:
@GetDocField(documentUNID; fieldname)
The documentUNID parameter is the universal ID of the document whose field value is to be read.
The fieldname parameter is the name of the item (fieldname) to read. This value is a string value. If the universal ID or fieldname are not valid, this function returns null.
The @SetDocField function sets a value of a specified field for a specified document. The syntax of this function is
@SetDocField(documentUNID; fieldname; value)
The documentUNID parameter is the universal ID of the document whose field value is to be modified.
The fieldname parameter is the name of the item (fieldname) to be modified. This value is a string value. If the universal ID or fieldname are not valid, this function returns null.
The value is assigned to the field. This can be a test value, text list, number, number list, time-date, or time-date range.