Според моя опит ER (или UML) диаграмите не са най-полезният артефакт - с голям брой таблици диаграмите (особено тези с обратно проектиране) често са голяма заплетена бъркотия, от която никой не научава нищо.
За моите пари, добра документация, която може да се чете от човека (може би допълнена с диаграми на по-малки части от системата) ще ви осигури най-много пробег. Това ще включва за всяка таблица:
- Описания на това какво означава таблицата и как се използва функционално (в потребителския интерфейс и т.н.)
- Описания на това какво означава всеки атрибут, ако не е очевидно
- Обяснения на връзките (външни ключове) от тази таблица към други и обратно
- Обяснения за допълнителни ограничения и/или задействания
- Допълнително обяснение на основните изгледи и процеси, които докосват таблицата, ако вече не са добре документирани
С всичко изброено по-горе, не документирайте заради документирането - документацията, която препоказва очевидното, просто пречи на хората. Вместо това се съсредоточете върху нещата, които ви объркаха в началото, и прекарайте няколко минути в писане на наистина ясни, кратки обяснения. Това ще ви помогне да го обмислите и то масово помогнете на други разработчици, които се сблъскват с тези таблици за първи път.
Както споменаха други, има голямо разнообразие от инструменти, които да ви помогнат да управлявате това, като Enterprise Architect, Red Gate SQL Doc и вградените инструменти от различни доставчици. Но докато поддръжката на инструменти е полезна (и дори критична в по-големите бази данни), върши тежката работа по разбирането и обяснение концептуалният модел на базата данни е реалната печалба. От тази гледна точка можете дори да го направите в текстов файл (въпреки че ако го направите във форма на Wiki, ще позволи на няколко души да си сътрудничат при добавянето към тази документация постепенно - така че всеки път, когато някой разбере нещо, той може да го добави към растящото тяло на документацията незабавно).
