In mijn ervaring zijn ER- (of UML)-diagrammen niet het meest bruikbare artefact - met een groot aantal tabellen zijn diagrammen (vooral reverse-engineered) vaak een grote ingewikkelde puinhoop waar niemand iets van leert.
Voor mijn geld zal een goede, door mensen leesbare documentatie (misschien aangevuld met diagrammen van kleinere delen van het systeem) de meeste kilometers opleveren. Dit omvat, voor elke tafel:
- Beschrijvingen van wat de tabel betekent en hoe deze functioneel wordt gebruikt (in de gebruikersinterface, enz.)
- Beschrijvingen van wat elk kenmerk betekent, als het niet duidelijk is
- Uitleg van de relaties (buitenlandse sleutels) van deze tabel naar anderen, en vice versa
- Uitleg van aanvullende beperkingen en/of triggers
- Aanvullende uitleg van belangrijke standpunten en procedures die de tafel raken, als ze niet al goed gedocumenteerd zijn
Met al het bovenstaande, documenteer niet om het documenteren - documentatie die het voor de hand liggende herhaalt, zit mensen alleen maar in de weg. Concentreer je in plaats daarvan op de dingen die je in het begin in de war brachten, en besteed een paar minuten aan het schrijven van heel duidelijke, beknopte uitleg. Dat zal je helpen erover na te denken, en het zal enorme help andere ontwikkelaars die deze tabellen voor het eerst tegenkomen.
Zoals anderen al hebben vermeld, is er een grote verscheidenheid aan tools om u te helpen dit te beheren, zoals Enterprise Architect, Red Gate SQL Doc en de ingebouwde tools van verschillende leveranciers. Maar hoewel toolondersteuning nuttig is (en zelfs cruciaal in grotere databases), doet het harde werk van begrijpen en uitleggen het conceptuele model van de database is de echte overwinning. Vanuit dat perspectief kun je het zelfs in een tekstbestand doen (hoewel als je het in Wiki-vorm doet, meerdere mensen kunnen samenwerken om stapsgewijs aan die documentatie toe te voegen - dus elke keer dat iemand iets bedenkt, kunnen ze het toevoegen aan het groeiende lichaam van documentatie direct).