(注意:我意识到这接近How do you document your database structure?，但我不认为这是完全相同的.)
我开始在一个地方工作，那里有一个数据库，几乎有数百个表和视图，所有的表和视图都有神秘的名字，只有很少的元音，而且没有文档.他们也不允许对数据库模式进行无谓的更改，我也不能在自己的机器上touch 任何数据库，除了测试数据库(它会被吹走并定期重新创建)，因此我不能添加对任何人都有帮助的注释.
我试着用"癞蛤蟆"创建一个ER图，但在让它连续运行48小时后，它仍然没有生成任何可见的内容，我需要回我的计算机.我在和其他最近的员工交谈时，我们都建议，每当我们弄不清楚某个特定的表或它的某些列是什么意思时，我们应该在developers wiki中更新它.
那么，有什么好方法可以做到这一点呢？只需列出表/视图及其列，并在进行时填写它们就可以了？我手头的基本工具是Toad、Oracle的"SQL开发者"、MS Office和Visio.
根据我的经验，ER(或UML)图并不是最有用的工件——因为有大量的表，图(尤其是反向工程的图)通常是一团混乱，没有人从中学习到任何东西.
就我个人而言，一些良好的人类可读文档(可能会辅以系统较小部分的图表)将为您提供最有效的帮助.对于每个表格，这将包括:
有了以上所有内容，不要为了记录而记录——重述显而易见的东西的记录只会妨碍人们.相反，把注意力集中在一开始让你困惑的事情上，花几分钟时间写清楚、简洁的解释.这将帮助您仔细思考，并帮助其他第一次遇到这些表的开发人员.
正如其他人提到的，有各种各样的工具可以帮助您管理它，比如Enterprise Architect、Red Gate SQL Doc，以及来自不同供应商的内置工具.但是，尽管工具支持是有帮助的(在更大的数据库中甚至是关键的)，但通过understanding和explaining的艰苦工作，数据库的概念模型才是真正的胜利.从这个Angular 来看，你甚至可以在一个文本文件中完成这项工作(尽管以Wiki的形式进行这项工作可以让几个人协作，以增量的方式向文档中添加内容——因此，每当有人发现某个内容时，他们都可以立即将其添加到不断增长的文档中).