Lately I have been working on a database diagram (Entity Relationship Diagram) for a project that is over a decade old. I don’t know if there ever was a diagram for this system. So I am reverse engineering one to show how all the pieces fit together in a logical fashion.
There are a lot of reasons why we don’t take the time to create a database diagram:
- The database may not be very big, and it is easy to keep all the entities and their relationships straight in ones mind.
- Databases are self-describing. This allows a person working with a database to gather the information necessary for the immediate task in a fairly simple fashion, without requiring a diagram.
- Databases are often fluid structures, changing over time. Perhaps a diagram was created for the original database, but changes have been made that were not maintained in the diagram. Over time, the diagram no longer matches the current database, and is less useful.
- The database may be very large, and thus difficult to diagram if the individual doesn’t know how to break the database down into different subject areas.
- Tools for diagraming are not available making documentation much more difficult.
Often, a diagram of the database, broken out by subject areas, is more than adequate. For a larger database, this makes it easier to find sections of the database representing a current problem. One large diagram can become confusing due to overlapping lines, and size. It’s much easier to thumb through a set of subject areas, and even place those of current interest side by side, than it is to try and view two different segments of a database that are separated by a whole wall full of tables.
In my experience, it is worth the time to document your database. It saves time in the long run because you don’t have to continually run queries, or drill into table definitions. Flip a couple pages, and you have everything you need at your fingertips. Moreover, it covers more than a single entityat a time.
As time goes on, it is also worth keeping this document current. The same reasoning applies as to why you created it in the first place. By creating the documents in the first place you optimize you development because everything you would have to look up is already prepared for you. The same holds true to maintaining the document in an on-going basis. Do you research once, and present it in a manner that reduces time.
A diagram optimized database interaction, even when you have Intellisense. Intellisense only works when you know what entity names are, and how entities are related. All that is made clear in a diagram. Now you can use intellisense to assist you in getting tables and columns correct, and to speed up your typing.
I still believe in diagraming. Most developers I have worked with the last 10 years have little interest. What do you think? Is this an old school mindset, or something relegated to the DBA? Share your thoughts in our comments or drop an email to btaylor@sswug.org.
Cheers,
Ben