|
|
|
|
|
|
|
|
|
|
|
|
|
|
Notes is not a relational database (continued)
When such a document is saved, Notes will attempt to save all the fields (except for Computed for display fields, not part of the storage) back to the document that was opened. It is possible to write code that will actually save these various values back to different documents, and Notes has the event model that will enable this to be done.
The denormalised data also requires some housekeeping activities, such that if, for example, constraint table values (not that Notes actually implements constraint tables per se) are stored in Notes, changes to values such a table will require code to go through all the places where the data is stored, denormalised, to propagate the change. This isn't a Notes specific issue, but it happens more often in Notes because Notes applications are more likely to implement denormalised data.
Whatever is done to make the Notes applications model a complex data model, the resulting application will inevitably be much more like a conventional transaction processing app, or a J2EE application, in that procedural code is written to pull all the data on to the screen, and more code to write it all back to the relevant data sources when saving.
All Notes would be doing is managing the display of the data, and maybe some replication work, and much of what makes Notes Notes would not be used. Because Notes's internal model is not geared towards writing applications like this, doing so is lengthy and may actually be more complex than using an environment that closer models the situation.
The performance of the Notes application may also not be good, because there will be a larger number of interactions between client and server -- again, outside the Notes model which is to open a single document, with a few, probably locally cached, lookups, and saving all the data to one place in one network interaction.
However, doing all of this still means that there is no commit/rollback process; Notes does not have one. Theoretically it is possible for the developer to create one, but you just wouldn't. It would be hugely complex, hugely slow, and unlikely to be proof against all the issues that might happen, such as being able to recover after a power failure.
So, Notes just isn't a relational database -- it's different, powerful and unique. Even with Notes data stored in DB2, the application won't be relational. It will still be a Notes application, and still be the powerful and unique thing that we all know.
With DB2 it just means that the power of the industry-leading relational database is used to store the Notes data. But what that does mean is that some of the power and capability of DB2 can be brought to Notes applications in Domino 7, and we can hope that it also means that the doors are opening in Domino to some more RDBMS operational functionality in later releases, such as the ability to define units of work, and commit and roll them back.
DB2 and Notes sounds to me like really, really good news.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-- Advertisement --
Find unused Lotus Notes groups and clean up your address book
Have you ever wanted to get rid of old Lotus Notes groups that were cluttering up your address book, but you weren't sure if they were used? Find Unused Groups can help.
Find Unused Groups will check your ACL, mail, multi purpose and server groups to help you determine if they are used, and who uses them.
Learn how to easily clean up your address book. |
-- Advertisement --
Mark your calendar for in-depth Lotus training, May 12-14, Boston
Join experts and peers May 12-14 in Boston for educational and networking events that deliver real-world Lotus training so you can increase productivity and efficiency in your company, advance your skills, and squeeze the most from your current environment. One registration gets you into THE VIEW's Admin2010 and Lotus Developer2010.
Register by April 10 to save $200. |
|
|
|
|
|
|
|
|
|
|