I attended an excellent presentation on MongoDB by Joe Feser at the Charlotte Enterprise Developers Guild recently. The presentation was well thought out and very favorable toward the enterprise wide use of NoSQL databases and MongoDB in particular. In discussing the use of the database Joe indicated some of the limitations MongoDB suffers from. Among them were the lack of foreign key structures and lack of transaction capability.

In spite of its limitations I can see several uses for a NoSQL database. None of which would be as an enterprise data store. Among them would be storing user session variables for a website garden or farm, or, variable values for a dropdown list or list box. On reflection I came to the conclusion that the inability to directly manage transactions and constraints relative to foreign keys and the like does not protect the data my company needs protected.

In not having foreign key constraints I am at the mercy of every application and database developer to ensure data integrity is persisted. The inconsistency of validation in enterprise applications based on developer input is significant. Unless the business specification calls for specific validation, a given developer may use any combination of validation code blocks to ensure consistent data, but their choices may not cover all bets. The reporting functionality of a particular enterprise application may have its accuracy and validity called into question because of inconsistent data validation and control of data in the database.

Along the same vein transaction management is just as important. Transaction management prevents data inputs or updates to multiple tables unless each table successfully completes its transaction. One failure in and actions results in all the tables being rolled back. MongoDB does not handle this important task of data integration across multiple documents. Yes, MongoDB has a two phase commit process, but it impacts only one document at a time. If several documents are being updated as part of a process action there is no internal means to ensure documents updated early in the process are rolled back upon an error in a document updated later in the process.

I can handle a performance hit that keeps my data intact and clean. I would hate to go to management and try to explain why reporting no longer reflects the accurate information they need to make good decisions; or, explain to management why users no longer trust the integrity of the data stored in the database.

I recognize MongoDB has interesting uses and is used by some very large organizations as their primary data store, but I have some concerns about its use in the enterprise. I would be interested in reading your thoughts on this issue.