Notes document is primitive compared to CouchDB JSON document

A Notes document is limited to name/value pairs of primitives (number,string,date) and lists thereof.

Notes applications often required more complex structures that could be represented by these limited types. Those structures were encoded into strings (and strings thereof), traditionally using the | as the separator. Much of the application code then consisted of logic to pack and unpack these representations.

JSON allows the CouchDB document to contain an arbitrary object tree. A wide variety of tools are available for parsing and data binding, further reducing the development effort.

The invoice address quandary

The attendees at the Dallas TechFest presentation on CouchDB were concerned with the apparently lack of normalization in capturing the address as part of an invoice document. Their primary concern was how to change that address when it changes.

That concern appears to reflect an inappropriate approach to data modelling and the type of historical data required for audits and SOX compliance.

The address on the invoice reflects the value that applied at the time the invoice was generated. That address is part of a primary key that identifies the legal entity that was responsible for the invoice. That entity might cease to exist, move, be merged, acquired or divested.  Even the move has non trivial legal consequences since it might impact taxes, export regulations, etc. Maintaining that historical value can be critical.

Ideally the invoice would not indirectly reference the affected legal entity by name+address, but rather by some unique identifier. Some countries define unique identifiers as part of the company registration process, but these (AFAIK) apply to the organization and not to individual locations. A WalMart can impose its own identification scheme on its suppliers. There are organizations that provide identifiers (such as Dun & Bradstreet) but those are limited in scope and potentially costly to acquire and use.

Organizations are thus forced to maintain their own directory of entities (parties) and perform a mapping from name+address to their own identifier. That leaves open the possibility of error, which cannot be resolved if the source name+address was not captured as part of the invoice. This is one reason for the popularity of document scanning and off-site archival systems, so that information can be retrieved if necessary.The cost of storing the textual representation is very much smaller than that of the scanned image or the storage and retrieval of the original paper document.

Auditing concerns would prohibit the modification of the master document.

The perceived CouchDB concern is thus a feature rather than a defect.

Couchdb thoughts from Dallas Techfest

The Dallas TechFest had an interesting presentation on CouchDB by Scott Davis.

Most of the attendees expressed various degrees of shock, horror and disbelief! The concepts of CouchDB are certainly very unusual for developers with a SQL background.

Those concepts are much more familiar to Lotus Notes developers and it might be useful to revisit the design patterns used in creating Notes applications.