Efter min erfaring er ER (eller UML) diagrammer ikke det mest nyttige artefakt - med et stort antal tabeller er diagrammer (især omvendt manipulerede) ofte et stort indviklet rod, som ingen lærer noget af.
For mine penge vil noget god menneskelig-læsbar dokumentation (måske suppleret med diagrammer over mindre dele af systemet) give dig flest kilometertal. Dette vil for hver tabel inkludere:
- Beskrivelser af, hvad tabellen betyder, og hvordan den bruges funktionelt (i brugergrænsefladen osv.)
- Beskrivelser af, hvad hver egenskab betyder, hvis den ikke er indlysende
- Forklaringer af relationerne (fremmednøgler) fra denne tabel til andre og omvendt
- Forklaringer af yderligere begrænsninger og/eller triggere
- Yderligere forklaring af vigtige synspunkter og procedurer, der berører tabellen, hvis de ikke allerede er veldokumenterede
Med alt det ovenstående skal du ikke dokumentere for dokumentationens skyld - dokumentation, der gentager det åbenlyse, kommer bare i vejen for folk. Fokuser i stedet på de ting, der forvirrede dig i starten, og brug et par minutter på at skrive virkelig klare, præcise forklaringer. Det vil hjælpe dig med at tænke det igennem, og det vil massivt hjælpe andre udviklere, der løber ind i disse tabeller for første gang.
Som andre har nævnt, er der en lang række værktøjer til at hjælpe dig med at administrere dette, såsom Enterprise Architect, Red Gate SQL Doc og de indbyggede værktøjer fra forskellige leverandører. Men selvom værktøjssupport er nyttig (og endda kritisk i større databaser), gør du det hårde arbejde med at forstå og forklarer den konceptuelle model af databasen er den rigtige gevinst. Fra det perspektiv kan du endda gøre det i en tekstfil (selvom at gøre det i Wiki-form ville give flere personer mulighed for at samarbejde om at tilføje til den dokumentation trinvist - så hver gang nogen finder ud af noget, kan de tilføje det til den voksende krop af dokumentation øjeblikkeligt).