In many organizations, it's expected that any persistent data
will be stored in relational databases that are managed by a central
database management group. There are various reasons for such
central control, usually centered around using IntegrationDatabases.
Central data groups worry about keeping out malformed data, queries
that can slow down important shared resources, and consistent data
models across the enterprise.

Worthy these aims may be, but one consequence of them is
considerable ceremony about storing data. I often hear complaints
about change orders that take weeks to add a column to a database.
For modern application developers, used to short-cycle evolutionary
design, such ceremony is too slow, not to mention too annoying.

So application development groups tell me of using NoSQL
databases to do an end-run around the DBAs. It helps that they are
using a "mere datastore" here, not a "proper database". That way the
DBAs can be kept out of the loop, often not told or happy to not
care. [1]

There's both good and bad in all this. On the good side, this
helps break what is often a troubling bottleneck for many
organizations' application development. The sad divide between
application developers and database professionals causes many
problems, and the poor take up of many moderndevelopmenttechniques
in the DBA community stifles much development. Shared
databases are a poor integration mechanism, and NoDBA
development leads to a useful push towards web services as the
basis for integration. [2]

On the negative side, using a technology for social reasons can
often lead to a poor use of the technology. It's not hard to imagine
people using a NoSQL database to avoid the DBAs when a relational
ApplicationDatabase would be a better choice. Data is
often a vital asset, and bypassing DBA groups may also mean
bypassing operations groups that know how to keep valuable data
backed up and secure.

The real answer, of course, is engagement with data professionals
along the lines of the devops movement. It's the barriers between
groups that cause much of the ceremony, few data groups are
populated by devils. We've seen success from inviting DBAs to
stakeholder meetings where they get to engage with the broad aims of an
application. We've also had NoSQL projects where we've reached out to the
DBAs, helped them learn about this new technology, and got valuable
help in supporting data needs. So although the NoDBA strategy is
sometimes appropriate, engagement is often better.

Acknowledgements

As usual, I found the discussion of the draft of this article on our
internal list very interesting. I particularly raided David
Pattinson's contribution.

Notes

1:
It seems particularly common to use MongoDB in this context
citing MongoDB's ease of installation, configuration, and use.

2:
A large part of the slow response to change requests is that
many incumbent databases are in essence complex legacy
applications at the centre of a large web of dependencies. These
databases are brittle and untested (Detestable), so it's no surprise that the
DBAs who look after them are wary of making changes. Such
systems would make even the smartest developer gun-shy of making changes.

Share:

if you found this article useful, please share it. I appreciate the feedback and encouragement