At Red River Software, we use a variety of technology to provide the optimal solution to customers. For some customers projects we use Microsoft SQL Server, for others we use MongoDB. NoSQL databases like Mongo have been gaining traction in the marketplace for some years now, and are popular as they aggregate data (the opposite of normalisation).
To anyone who is familiar with Lotus Notes on an API level, the internals of MongoDB give some sense of déjà vu. With document GUIDs and replication, it all sounds familiar.
Lotus Notes / Domino is still in use in many blue chip corporations, usually as legacy applications. Lotus Notes was designed in a pre-internet era, and so has a strong cryptographic authentication core based around Organisational Root certifier ID, Server IDs, and User IDs. In the world of the internet, a real time authentication mechanism such as OAuth is probably preferable. The downside to any ID file system is (a) physical security of the ID files, and (b) the cost in man-days of re-establishing trust in case of a breach. A real-time internet authentication mechanism allows tokens with much shorter lifespans than the previous IDs.
There are other noticeable differences. In many cases lightweight applications using Lotus Notes stored programs forms views as notes in the database, so code could be deployed with data. This isn’t a normal activity in Mongo, but this could be implemented, but probably wouldn’t be that efficient. With web services, this is no longer necessarily relevant.
Other differences include the fact that a Note in a Lotus Notes database is essentially a flat file – a single level document with named items in it, whereas in Mongo a document is a JSON tree. Note: it is possible to convert from XML to JSON using various tools.
JSON as a format is less redundant than XML and therefore more efficient. However, doesn’t have as established a schema validation system as XML, and doesn’t have namespaces.
In general, although tools like Entity Framework take the work out of SQL, the underlying tables and joins to model a complex set of hierarchical data can be bewilderingly complex, and the performance impact difficult to predict.
In comparison, apart from through using ODBC Mongo drivers, which allow Mongo to be seen as SQL and therefore joined, the equivalent in Mongo, as was true with Lotus Notes is that it’s common to have a bit more redundancy (as opposed to perhaps over-normalisation), and then update data on event or by scheduled service.
Where Mongo comes into its own in the Cloud world, is the way that JSON can interact with AngularJS in the browser. The JSON document from the Server becomes an object tree that can be interacted with easily either using AngularJS or other JavaScript frameworks, making a very clean overall solution.
In conclusion, some corporate applications formerly used Lotus Notes as opposed to SQL as a back end database due to Lotus Notes’ strengths in replication and unusual data model. It certainly seems like the majority of these legacy applications could be ported to Mongo, with application improvements possible in more capable data-model, simplified user interface coding, and more rapid application development.
