Defining a Domino Database

A Domino database is not like a relational database; it is an unstructured or, at best, semi-structured database. Relational databases, on the other hand, are structured. In relational databases, a table is defined by its fields, and each field also is structured (with the exception of Memo fields, which are similar to Domino rich-text fields). For example, you might define a customer table in a relational database as shown in Table 2.1.

Table 2.1. Relational Database Table Structure

This example of a structured data table has a definable disk presence. The record size is the sum of bytes in the Width column plus 1. In this example, there are eight fields and the record size is 177. So, if you input 100,000 records, the size of the resulting database would be 17,700,000 bytes, or roughly 18MB. Additional disk space is consumed by the file header, which must be added to the total bytes from the records to get the total file size. The point here is that the database is structured, definable, and quantifiable. Each record contains all the fields in the table definition, regardless of whether any data is present in the fields.

On the other hand, it is difficult to predict the ultimate size of a Domino database, even if you know the number of documents. Databases are collections of documents; documents contain fields ( strictly speaking, they're called items ”see the following note), which are the basic units of information in Notes, just as they are the basic units of information in the relational database described in Table 2.1. However, when you pick a field type in Domino, you don't specify the width. For cCustomer , you simply choose Text as the field type; no option for width exists. A user can type a couple of words or a couple of paragraphs into that field. Therefore, record size cannot be defined in Notes as it is in Table 2.1.

NOTE

Technically, data elements in a Domino database are called items; the term fields refers to the objects on a form that enable you to create and modify items. However, I generally refer to fields instead of items to avoid confusion.

Domino doesn't necessarily add disk space when you add a document. If Domino determines that more disk space is needed, it adds space based on an internal algorithm that can accommodate several new documents. When documents are deleted, Domino leaves a deletion stub but doesn't immediately release the disk space. These document stubs are important because they are used to properly replicate the deletions to any other replica copies of the database that exist. Then, after a defined period of time (90 days, by default), the document stub is deleted. The space left by the deletion of the document or the deletion stub is referred to as whitespace. The whitespace can be reused by new documents, or you can compact the database to remove the whitespace (see the section "Working with Database Properties," later in this chapter). Again, the amount of disk space for a given number of documents cannot be accurately calculated.

To further complicate matters, there is no fixed definition of a document as there is a fixed definition of a record in a relational database table. Different documents can and do have different fields, even though they might all have been created and edited with the same form. Fields can be added or removed programmatically from a document in a variety of ways, which you'll learn as you read this book. You can examine the fields in a document by right-clicking the document and choosing Document Properties from the menu. Choose the Fields tab, and you can scroll through the list of fields, as shown in Figure 2.1.

Figure 2.1. The Fields tab in the Document properties dialog box provides a window to the field information for each item in a document.