The Problem with Data Architecture for IBM Notes Domino XPages Apps

12/15/2015 11:15:00 AM by Chris Toohey

Traditional NotesDatabase data architecture was simple: you have a notesDocument with a unique ID, and if you want to create a relationship between that notesDocument and another notesDocument, you used the Parent-Child relationship that's one of the core tenants of the NotesDatabase architecture. The child document would have a notesItem named "$Ref", and the parent document's UniversalID (the aforementioned "unqiue ID") would be stored in the "$Ref" of the child document. From here, a child could easily get the parent notesDocument, and the parent could use a categorized View (the category being @Text($Ref)) to get a collection of all of the child notesDocuments.

Basic stuff really.

In an attempt to create psuedo-relational data architectures in notesDatabases, a lot of us got into the habit of creating our own keys. By creating a unique-per-need key, we could join various notesDocuments and create whatever types of relationships our particular application needed.

Displaying those relationships, however, was often tricky.

Mind you, we found ways around the limitations of displaying poly-relational data architectures in traditional Lotus Notes designs, but I don't think things really got crazy until XPages was an option.

With XPages, we were no longer limited to our notesDocument and "related" notesDocument architectures. Since we had the ability to display and better manipulate data...

I'll give you an example:

If I wanted to create a one-sheet invoice Form, I'd have some options available to me as a developer using IBM Notes Domino with XPages:

• A single notesDocument with "customerNumber_001", "customerNumber_002", etc. fields.
• A parent notesDocument with child notesDocuments for each line item on the invoice.
• Joining and splitting a multivalue "customerNumber" notesItem.
• Storing all line items as a JSON object in a single notesItem.
• ... and various other ways I'm not even touching base on in this post.

The thing is, however, that each of these techniques has as many reasons that support the technique, and almost an equal number of reasons to avoid said technique.

Maintenance of "_001" notesItems can be a nightmare. Traditional Parent-Child and custom poly-relational [custom key(s)] can result in orphaned notesDocuments. JSON Object manipulation via LotusScript is a pain.

The problem with Data Architecture for IBM Notes Domino XPages Apps is that there are often too many choices... and it is the demands of the data - both what you're storing and what you need to do with the data once you're storing it - that should lead you to choose one technique over another.

• Simple, one-shot apps can get to deployment faster and have more easily-reportable data using the "_001" approach (regardless of how unclean it feels).
• Parent-Child and custom-key poly-relational documents can allow for rich content storage.
• I'm a fan of multivalue delimited data blobs... for certain use cases.
• And JSON objects offer fast, reliable in-notesDocument simple data storage.

"It depends" is a legitimate response when asked which method is best, as it absolutely does depend on multiple factors. So look at the demands of the application - specifically what type of data will be stored and how that data will be used - to guide you in designing your application data architecture.