Where’s your database’s ER Diagram? by Scott Selikoff.
From the post:
I was recently training a new software developer, explaining the joys of three-tier architecture and the importance of the proper black-box encapsulation, when the subject switched to database design and ER diagrams. For those unfamiliar with the subject, entity-relationship diagrams, or ER diagrams for short, are a visual technique for modelling entities, aka tables in relational databases, and the relationships between the entities, such as foreign key constraints, 1-to-many relationships, etc. Below is a sample of such a diagram.
Scott’s post is particularly appropriate since we were talking about documentation of your aggregation strategy in MongoDB.
My experience is that maintenance of documentation in general, not just E-R diagrams, is a very low priority.
Which means that migration of databases and other information resources is far more expensive and problematic than necessary.
There is a solution to the absence of current documentation.
No, it isn’t topic maps, at least not necessarily, although topic map could be part of a solution to the documentation problem.
What could make a difference would be the tracking of changes to the system/schema/database/etc. with relationships to the people who made them.
So that at the end of each week, for example, it would be easy to tell who had or had not created the necessary documentation for the changes they had made.
Think of it as bringing accountability to change tracking. It isn’t enough to track a change or to know who made it, if we lack the documentation necessary to understand the change.
When I said you would not necessarily have to use a topic map, I was thinking of JIRA, which has ample opportunities for documentation of changes. (Insert your favorite solution, JIRA happens to be one that is familiar.) It does require the discipline to enter the documentation.