以我的经验，ER（或UML）图并不是最有用的工件-拥有大量的表，图（尤其是反向工程图）通常是一个大杂乱无章的混乱，没人能从中学到任何东西。

为了我的钱，一些良好的可读性文档（也许在系统的较小部分以图表的形式进行补充）将为您带来最大的收益。对于每个表，这将包括：

• 该表的含义及其功能使用方式的描述（在UI中等）
• 每个属性含义（如果不明显）的描述
• 该表与其他人之间的关系（外键）的解释，反之亦然
• 附加约束和/或触发器的说明
• 如果还没有很好的记录，对与表格相关的主要视图和过程的附加说明

对于上述所有内容，请不要出于文档目的而进行文档记录-
重述显而易见的文档只会妨碍人们的操作。相反，请专注于起初使您感到困惑的内容，并花几分钟编写真正清晰，简洁的说明。这将帮助您仔细考虑，并且将 极大地
帮助其他首次遇到这些表的开发人员。

正如其他人提到的那样，有许多工具可以帮助您管理此问题，例如Enterprise
Architect，Red Gate SQL Doc以及各种供应商提供的内置工具。但是，尽管工具支持很有帮助（在更大的数据库中甚至是至关重要的），但努力
理解 和 解释
数据库的概念模型才是真正的胜利。从这个角度来看，您甚至可以在一个文本文件中进行操作（尽管以Wiki形式进行操作可以使几个人进行协作，以逐步将其添加到该文档中-
因此，每当有人发现某些内容时，他们都可以将其添加到不断增长的主体中文档）。