I went back and forth about what I would first write about, and decided that programming seems to be the area that most needs attention. That being the case, my first few blog entries will be related to development.
With this first entry, I think an explanation of the overall programming items is ideal. I will discuss the objects available, what version they became available in (if I know), and what they are used for (whether by design or creative use).
That's right, the database is its own design object. It has properties and methods, and events. While it is obvious that it is the place data is stored, the NSF is its own unique sort of data store. It is often classed as a "flat file" database, and perhaps that is a good category. I will often refer to it as an XML database, as it was built upon the SGML standard that brought us HTML and XML. In addition, it is a data structure built around documents, not records. You could easily represent every data object (document) stored in a Notes/Domino database using the following XML structure, where of course you change items to real world values.
This fact is clearly "brought to light" by the fact that there is a new function in Notes databases (since Notes/Domino 6 I believe) called DXL which is essentially a way to represent everything in a database in XML.
How it Stores Data
Like an XML document (in this case the data between the <DOCUMENT> tags) , a document in a Notes/Domino database can contain varying "structure". A document is a Notes/Domino database can contain data fields of any type, with any acceptable name. It is just a collection of data - there is no design to it, again, just like XML.
For example, an email message is a document in your mail database. All of them contain some basic fields, like the sendto, copyto, subject, and body fields. However, as you manage your inbox you might add flags to a messsage for a reminder, or it might have come with a mood stamp on the message. Though all of these documents represent data created with Memo form, Reply form, or Reply to Reply form (which are very similar), they will not contain all the same fields. When you flag a message for say a follow up, it adds a field to indicate your choice, but other messages you have not done this for do not. Thus the <FIELD> list of values for the marked document would be different than the ones unmarked. This is a basic functionality of documents - there is no real limit to how you can leverage this. Some (mostly with a relational database background) would argue this is a bad thing, and it can be as it means data is not "normalized", but it can also be a beneficial thing - and it is often a very powerful feature of Notes/Domino databases.
So a Notes/Domino database is a collection of Documents that store data. That is it.
You may be saying to your self right now, well what about design elements like views and outlines? Guess what, they are documents, special kind of documents of course, but documents nonetheless that contain data which represents the structure and configuration of said design elements. The Notes/Domino database just knows how to use those special documents to function as functionality. And guess what, if you wanted to (though I can only think of a few rare cases where you would) you can add or manipulate the fields of a design element just like you can of a data document.
What is it used for - when started
While likely quite obvious, the Database has always been a part of Lotus Notes/Domino. As discussed above it is used to store data and design of an application. This is what it was designed for, and I have never really seen it used for anything else - unlike many other design elements (as we will see in future articles).
Next lesson we will discuss the FORM object.
Until then, let me know what you think of this article as it will be a template going forward.