Lotus Notes is not a relational database – difference between Notes database and RDBMS
How does this differ from an RDBMS?
There are several areas of difference between Notes and a traditional relational database management system.
1. Notes keeps application code and data in the one database.
For sure, many RDBMS keep code in the database, as stored procedures, but this code is mainly database management code that deals with properly managing database operations, rather than implementing business and application logic.
Notes does not have any concept of code that is attached to data storage events. QuerySave and other events are attached to UI objects, and their operations. Notes’s application code is all kept in the database, and replicates with it.
Some application developers who have created API code have developed ways of keeping that code in the database too, as attachments, and having it detached automatically by the Notes application, so leveraging the replication model to distribute non-Notes application components.
2. Notes has no schema, and does not implement Referential Integrity
Notes doesn’t have a schema. It has no concept of tables or keys, and so cannot implement referential integrity. As far as Notes is concerned, all data notes are data notes; differentiation between them is down to their contents only, and not to any structural attributes.
For example, the field FORM is used by the Notes UI to tell what Notes form — screen mask — is to be used to display note data on the screen. Another example: views, which act as database indexes, have a selection formula; the developer uses this to select the data notes that are to be included in that view.
Commonly the Form field value is used, which is about as close as Notes gets to an RDBMS table. A view can be sorted, and the first sorted column is about as close as Notes gets to table keys.
Because of this, Notes does not have Referential Integrity, and could not. If it is required in an application, standard Notes design and programming techniques are used to create an RI model for the application. The only structural relationship that Notes implements is the Response Hierarchy, which provides a parent-child relationship of documents.
For example, this is used in discussion type applications so that views, which can be made sensitive to this relationship, will generate and display threads of responses. It’s implemented by a pointer field in the response which points to its immediate parent. It does not have any rules attached to it, so that it is entirely possible to delete any document in the thread, and so logically break the thread. It’s up to the application developer either to prevent this happening, or to write code that repairs the thread.
A complete Notes application may also be several Notes databases. Notes of itself does not have any mechanism for management of relationships between these databases. For sure, there are programming fundamentals and tools for building multi-database applications, so that one database can look up, use and update data in another one, but Notes of itself does not know of, understand or maintain these for itself. If required, they have to be programmed.
3. Notes may keep Data as part of Design.
The most obvious implementation of this is the Notes keyword field. This is a partial implementation of constraint tables, in that it is used to provide a fixed list of values that can be entered into a field, but does not stop non-listed values being inserted into the field programmatically, because the keyword list is part of the UI object used to display the data, and isn’t an attribute of the storage of the data itself.
Keyword fields have a variety of implementations, in that choices can be a fixed or extendable list, can be displayed as a list choice, radio or checkboxes. The keyword list data can be canned in the design or looked up elsewhere in the same or another Notes application, or, with appropriate drivers, in an external database. Note that this last is not a good implementation choice, because it’s hard to distribute.
When the data is kept as part of the design, the choice list cannot be updated programmatically.
4. Notes is a distributed database
One of Notes key differentiators is the fact that it implements a peer-model distributed database, and delivers the replication process to keep these distributed replicas in sync.
One key part of this model is that there is no concept of a master copy of the database, so there is no mechanism for rejecting or even serialising conflicting updates.
There are mechanisms for detecting conflicts, and limited mechanisms for merging conflicting updates, but by and large, for the types of application that Notes is used for, the business model tends not to be one that can generate conflicts anyway.
5. Notes implements different field models.
One significant difference between Notes and any other database model is the concept of multi-value fields; basically the storage of an array in a single field. Notes actually stores all fields this way except for Rich Text fields. It’s most commonly seen in Notes email — the SendTo, CC and BCC fields are all implemented this way.
As well as no schema describing the contents of Notes documents, there is also no fixed mechanism for describing fields. A Notes field contains whatever data and data type it happens to contain, at the time, and the data type of a field can be changed programatically at any time, so long as the data stored matches that data type.
As well as the concept of numeric and string data, Notes natively stores dates, Notes names, and Rich Text which stores not only the data, but also formatting information for the data, and blob-type content.
When a field is defined on a Notes form, it’s given a data type. That data type is used to parse data that’s entered on the form, and store it as that type. It rejects data that doesn’t match the type specified on the form. But when displaying a document, Notes only uses the field definition on the form to know where to display the data.
It displays the data formatted in line with the stored field data type, overriding that specified in the form. Notes will happily display string data in what appears to be a numeric field. The Notes field type is only checked against the data when it needs to be — in the example given, Notes displays the data using the definition stored with the data, but if the document were edited, then the data in the field on the screen would then be validated by the form, and being string data in a numeric field, would probably fail the check.
6.Notes does not implement a Transaction Model.
The hallmark of an RDMBS is the concept of transaction isolation and recovery; should a transaction fail, it’s backed out, and while one user has hold of data items, they are unavailable to others.
Notes was designed to implement long, and distributed, transactions, and so does not have these facilities in it (actually edit locking was introduced in Notes 6). Notes users are able to take a replica copy of a database away, work with it, and then later replicate back all the work that they have done.
Should there be conflicts, they are handled or marked appropriately. These transactions are effectively days or even weeks long. Notes 6′s document locking also has the concept of provisional locks to support working offline.
Notes also does not have the concept of recoverable units of work, at least, not yet. The fundamental Notes principle is that of opening one document, working on it, and saving it all back to one place. Notes does guarantee that if a save operation completes, the whole document is saved, and if it fails, none of the data is stored, but that concept does not go forward to the idea of a developer definable set of operations that all have to succeed or fail together.
Viewed 379 times by 149 viewers
