- Services in the Box
- Domino Development
- Domino Databases
- Templated Design
- It's Dead Jim!
- Had Enough?
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Domino Databases
One of the most distinct things about Domino as a development platform is the database structure, or rather the lack of one. Domino databases are not relational and do not have a fixed data structure.
I've referred to Domino databases as data blobs. Domino databases seem to be something akin to a linked list of records comprised of a linked list of fields. In Domino terminology, records are called "documents" and fields are called "items."
Fields can be any of four data types: Rich Text, numeric, text, date-time, and names fields.
A Rich Text field is itself a data blob, like a combination CLOB and BLOB (Character and Binary Large OBject) field in Oracle databases. You can attach files, embed Microsoft Object Linking and Embedding (OLE) objects or images, store formatted text (text with formatting information such as fonts, colors, and paragraph spacing), or even store web page content (HTML, CSS, and JavaScript).
A Rich Text field can also contain hyperlinks to other Notes documents or web URLs and "hot spots" such as buttons with code embedded in them. You can also insert tables into Rich Text fields that let you format the layout of any of the rich content. Although the limit for a single rich text field is 1GB worth of information, I don't advise putting that much data into a single record for reasons that I'll explain later.
Text fields hold text (duh!). Unlike other database platforms, you don't have to specify a size limit to the text field. All text strings in Domino applications are stored as Unicode text. Any text field can hold 32k Unicode characters.
Date-time fields store time information including time zone information. A date-time field can store a date value, a time value, or both date and time information. As an example, on a form for a recurring meeting, one date-time field can be added to the form to store the time of day when the meeting starts. Another date-time field on the same form can be used to store the first date of the recurring event, and yet another date-time field can be used to store the date and time when the recurring meeting record was created. The same date-time field type can be used to define fields that store time, date or date and time information.
Domino is very intelligent in how it stores and displays time information. No time conversion is required to display time within the proper time zone. Because Domino was designed to support replication, date-time values are very important, as is figuring out the real difference between two different time values adjusted to a common time zone.
When Domino servers communicate with each other or with Notes clients, they know exactly the difference between their respective clocks. Domino adjusts time/date comparisons to take the time differences into account. When time values are displayed in Domino applications, these same automatic adjustments are used to display them.
For example, if you are in California and you receive a meeting invitation created by someone in your New York office, the meeting time would automatically be displayed at the correct time on your Notes Client. Your Notes Client knows its own time zone and that the meeting was set for a time in a different time zone and makes the adjustments automatically.
Names fields are used to store identities such as user names, server names, domain names, and user roles. A "reader" field is a names field that can be used to restrict who can read a record. An "author" field is a names field that is used to restrict who can modify a record. There can be multiple reader and author fields, all of which will be used to restrict read and edit access of the record.
Because Domino names fields can be set to be "computed" (their value is automatically reevaluated each time the record is modified), a formula can be used to provide conditional and dynamic access to records.
Computed names fields make it easy to design workflow applications, in which one user or group has access to the record when it is at a certain stage in the workflow, and a different set of users or groups have access to the record at a different stage in the workflow.
Restricting read and edit access at the record level is a second level of access rights in Domino databases. The first level is access restriction to the entire database.
If you can't access the database (via access granted in the ACL), having read or edit access to a record won't do you any good. Likewise, having access to a database at the ACL level won't do you any good if all the records in a particular database are restricted so that your user account does not have access to them.
The amorphous structure of Domino data means that you don't have to create a separate table for every different type of record you want to define. A single Domino database can contain records with many different structures.
For example, the standard Mail database can contain Memo records (email messages) and Calendar records, even though they have a different structure from each other.
In a relational database, you'd need a separate table for each kind of record. In Domino, there is a limit to how many different kinds of records you can have in a single database, but it has to do with how many different field names there are.
Being able to mix records means that an entire application with multiple record types could be accommodated in a single Domino database file. This is great for portability of your application because you can distribute a single file with several different kinds of records.
But mixing all your different record types into a single database isn't necessarily the best design for all applications.
The drawback to this data flexibility is that you can't compare the performance of a Domino database to an Oracle database, for example. An Oracle database can be tweaked to run circles around a Domino application because storage and memory structures for flexible record structures (Domino) cannot be optimized to the same degree as fixed record structures (Oracle).
But do you really need the same level of database performance for all your applications? Domino's benefit is that it is optimized for collaboration, ease of management, ease of distribution, and flexibility. They are great benefits for a distributed workforce and for simple applications.
This is not to say that you can't create complex applications using Domino. But you most likely wouldn't consider Domino for a transaction processing or data warehousing application.