Understanding the Database Structure
Domino databases are identified by a filename and a replica ID. The replica ID is unique in each database that is created and is used to identify each replica copy on multiple servers or workstations for the purpose of synchronizing the data. When synchronization occurs through replication, the replica IDs are compared before replication begins. A replica of a database does not need to be in the same path or have the same filename on each server or workstation. However, as a developer, it is not a good practice to change the filename or path for a database. The replica ID for a database can been seen on the Info tab of the Database properties dialog box in Figure 2.2.
Figure 2.2. The replica ID of a database is displayed on the Info tab in the Database properties dialog box.
Unlike relational database systems in which there are separate files for tables and programs, Domino stores all the data and all the programming and design elements for a database in one NSF file. This is a self-contained unit that is then very easy to distribute through the replication process. Instead of records, you find notes inside a Domino database. Many different types of objects in a Domino database are stored as a note. For example, the access control list (ACL) of a Domino database is stored in a note, each form created in a database is stored in a note, each view is a note, and so on. Some notes have only one instance per database, whereas others might have multiple instances. The ACL note has only one instance, whereas there are usually multiple form notes in a database.
Notes are not related to each other in any way, although the "wrapper" of a note does provide a label that defines its contents as that of a form, view, document, and so on. In other words, Domino databases are not relational databases because not all the notes are related to each other in any way (although relationships can be created programmatically). The identifying component of each note is the universal ID, also known as the UNID. You can see what a note ID looks like by opening the properties for a design element or a document, as shown in Figure 2.3.
Figure 2.3. Each note is identified by a UNID.
The most recognizable types of notes that are stored in the database are listed in Table 2.2.
Table 2.2. Note Types
| Note Type | Description |
|---|---|
| Design | Collection of all forms, views, pages, and so on. |
| Info | The database help "About Database" document. |
| Icon | The database icon. |
| Help | The "Help “Using Database" document. |
| ACL | The access control list for the database. |
| Page | Information other than fields. The information can be an embedded element, text, graphics, or hotspots. |
| Form | Note used to enter information into a document and to display a document. A form supplies a template for the layout of the user interface that you will provide for data input and viewing data. |
| View | Note that contains a list of documents programmatically selected to display specific information in a columnar format. |
| Folder | Note that contains a list of documents selected by the user to display specific information in a columnar format. |
| Outline | A method for providing a navigational structure to an application, through outline entries that can represent views, documents, other databases, and pages. |
| Document | A data note or record. |
| Item | A field note. |
| Outline | A note that contains the outline information for providing navigation of the database. |
| Navigator | Note that contains an image map for navigational purposes. |
| Frameset | A set of frames or display areas, used to display other design elements and documents whose contents are changed programmatically. |
| Agent | A set of instructions or a program that performs specific actions in your application based on a triggered event. |
| Shared images | A storage facility for image files (GIF, JPEG, BMP) that will be reused in other design elements. |
| Shared files | A storage facility for files that will be reused in other design elements. |
| Shared applets | A storage facility for Java applets that will be reused in multiple places within the database. |
| Subforms | A portion of a form that can be embedded in multiple forms within a database. |
| Shared fields | Field definitions that can be reused in multiple forms and subforms. |
| Script libraries | Storage facility for LotusScript and Java that will be reused in multiple places within the database. |
| Shared actions | Programmable hotspots that appear at the top of a view or form that can be reused in multiple views or forms. |
| Database script | Programmable events available at the database level. |
From Table 2.2, you can see that almost everything can be considered a note. How does this affect you as a developer who is looking to provide an application that is optimized for performance? Well, consider the following. I create a shared field that I then use in a subform. When I use this subform within a form, it will take longer for the form to open. To open the form, first the subform must be located, based on its note ID as specified in the form. Next, the shared field must be found within the database, again based on its note ID as specified in the subform. Does this mean that you shouldn't use shared resources? Not at all! But it does mean that you should be cautious of the number of shared elements you place in a form, as well as the levels at which you place the shared elements. The more shared objects there are, the longer it will take to open the document.
CAUTION
Do not add too many shared elements to the same form because it slows the time it takes to open the form.
So if the database contains a note for everything that I create, what is in that note? You can actually view some of that information by looking at the document properties for any document or design element that you have in the database. If I look at the document properties of a form, such as the one shown in Figure 2.4, there are items in the note that define the contents of the note.
Figure 2.4. The Design Document properties box displays all the items within the form note.
As a developer, you are accustomed to referring to items each time you access the data contained in a field because a field is referred to as an item. This is also true for the information stored in a note. If you look at the Design Document properties box shown in Figure 2.5, you will see that each item in the fields list contains different types of information describing the view and its contents. These are all considered items within the view note.
Figure 2.5. The Design Document properties box displays the items within the view note.