（注意：我意识到这与How do you document your database structure?很接近，但我不认为它是相同的。）
我已经开始在一个拥有数百个表和视图的数据库的地方工作，所有这些表和视图的名称都很神秘，元音很少，也没有文档。他们也不允许对数据库模式进行无偿更改，我也不能触摸任何数据库，除了我自己机器上的测试数据库（它会被吹走并定期重新创建），所以我不能添加对任何人都有帮助的评论。
我尝试使用“Toad”创建一个 ER 图，但在让它连续运行 48 小时后，它仍然没有产生任何可见的东西，我需要我的电脑回来。我正在与其他一些最近的员工交谈，我们都建议，每当我们对特定表或其中某些列的含义感到困惑时，我们应该在开发人员 wiki 中更新它。
那么有什么好的方法来做到这一点呢？只是列出表/视图及其列并在我们进行时填写它们？我手头的基本工具是 Toad、Oracle 的“SQL Developer”、MS Office 和 Visio。
##尝试使用此评论重新打开它
以我的经验，ER（或 UML）图并不是最有用的工件 - 有大量表格，图（尤其是逆向工程图）通常是一个大的错综复杂的混乱，没有人从中学到任何东西。
为了我的钱，一些好的人类可读的文档（可能补充了系统较小部分的图表）会给你最多的里程。对于每个表，这将包括：
综上所述，不要为了记录而记录——重申显而易见的文件只会妨碍人们。相反，专注于一开始让你感到困惑的东西，然后花几分钟写出非常清晰、简洁的解释。这将帮助您考虑清楚，并且将极大地帮助第一次遇到这些表格的其他开发人员。
正如其他人所提到的，有各种各样的工具可以帮助您管理此问题，例如Enterprise Architect、Red Gate SQL Doc以及来自不同供应商的内置工具。但是，虽然工具支持很有帮助（在更大的数据库中甚至是至关重要的），但努力理解和解释数据库的概念模型才是真正的胜利。从这个角度来看，您甚至可以在文本文件中执行此操作（尽管以 Wiki 形式执行此操作将允许几个人协作以增量方式添加到该文档中 - 因此，每当有人发现某些内容时，他们都可以将其添加到不断增长的正文中文件立即）。
要考虑的一件事是 DBMS 中内置的 COMMENT 工具。如果您对 DBMS 本身中的所有表和所有列添加注释，那么您的文档将位于数据库系统中。
使用 COMMENT 工具不会对模式本身进行任何更改，它只会将数据添加到 USER_TAB_COMMENTS 目录表。
我们使用Enterprise Architect进行数据库定义。我们包括在 UML 中定义的存储过程、触发器和所有表定义。该程序的三个出色功能是：
您可以在 UML 工具中编辑您的类/表定义，并生成包含图片的完整描述文档。自动生成的文档可以是多种格式，包括 MSWord。我们的模式中只有不到 100 个表，而且非常易于管理。
在我作为开发人员的 10 多年中，我从未对任何其他工具印象深刻。EA 一举支持 Oracle、MySQL、SQL Server（多个版本）、PostGreSQL、Interbase、DB2 和 Access。每当我遇到问题时，他们的论坛都会及时回答我的问题。强烈推荐！！
当 DB 发生更改时，我们在 EA 中进行然后生成 SQL，并将其签入我们的版本控制 (svn)。我们使用Hudson进行构建，当它看到您修改了签入的 sql 时，它会从脚本中自动构建数据库。
在我们的团队中，我们采用了有用的方法来记录遗留的大型 Oracle 和 SQL Server 数据库。我们使用Dataedo记录数据库模式元素（数据字典）和创建 ERD 图。Dataedo 带有文档存储库，因此您的所有团队都可以在线记录和阅读最近的文档。而且您不需要干扰数据库（Oracle 注释或 SQL Server MS_Description）。
首先，您导入模式（所有表、视图、存储过程和函数——带有触发器、外键等）。然后，您定义逻辑域/模块并将所有对象（拖放）分组到它们中，以便能够分析和处理较小的数据库块。对于每个模块，您创建一个 ERD 图并编写顶级描述。然后，当您发现表和视图的含义时，为每个表和视图写一个简短的描述。对每一列执行相同的操作。Dataedo 使您能够为每个对象和列添加有意义的标题——如果对象名称模糊或无效，这将非常有用。专业版使您能够描述外键、唯一键/约束和触发器——这对于理解数据库很有用但不是必需的。
您可以通过 UI 访问文档，也可以将其导出为 PDF 或交互式 HTML（后者仅在 Pro 版本中可用）。
这里描述的是一个连续的过程，而不是一次工作。如果您的数据库发生更改（例如，新列、视图），您应该定期同步您的文档（使用 Dataedo 进行几次单击）。
请参阅示例文档： http ://dataedo.com/download/Dataedo%20repository.pdf
关于文档过程的一些指南：
图表：
说明：
这是一篇关于如何处理数据库文档的好帖子：http ://www.simple-talk.com/sql/database-administration/database-documentation---lands-of-trolls-why-and-how/
wiki 解决方案支持超链接和协作编辑，但 wiki 仅与保持其组织和最新的人一样好。无论您使用什么工具，您都需要有人拥有文档项目的所有权。该人可能会涉及其他知识渊博的人来填写详细信息，但应由一个人负责组织信息。
如果您无法使用工具通过逆向工程生成 ERD，则必须使用 TOAD 或 VISIO 手动设计一个。
任何包含数百个对象的 ERD 都可能无法作为开发人员的指南，因为有这么多的框和行将无法阅读。在具有如此多对象的数据库中，很可能存在由几十个表和视图组成的“子系统”。因此，您应该为这些子系统制作自定义图表，而不是期望有工具为您完成。
您还可以设计一个伪 ERD，其中表组由一个图中的单个对象表示，而该组在另一个图中展开。
单个 ERD 或一组 ERD 不足以记录这种复杂性的系统，正如类图不足以记录 OO 系统一样。您必须使用 ERD 作为插图来编写文档。您需要对每个表、每列以及表之间的关系的含义和用途进行文本描述（尤其是在此类关系是隐式而不是由参照完整性约束表示的情况下）。
所有这些都是大量的工作，但这是值得的。如果有一个清晰且最新的地方记录模式，整个团队都将从中受益。
这个答案扩展了 Kieveli 的上述内容，我对此表示赞同。如果您的 EA 版本支持对象角色建模（概念设计，与逻辑设计 = ERD），请对其进行逆向工程，然后使用它为您提供的丰富表现力填充模型。
便宜和轻量级的选择是从 MS 免费下载 Visiomodeler，然后做同样的事情。
ORM（称为 ORMDB）是我发现的唯一一个支持和鼓励与非 IS 利益相关者就 BL 对象和关系进行数据库设计对话的工具。
现实检查 - 在生成 DDL 的过程中，它会经过一个完整的 ERD 阶段，您可以在此满足您关于它是否有任何问题的问题。它没有。它可能会向您展示您自己设计的 ERD 的弱点。
ORMDB 是工具越概念化，市场越小这一原则的经典案例。女孩只想玩得开心，程序员只想编码。
由于您有幸与同一条船上的其他开发人员一起工作，我建议您询问他们认为最容易传达所需信息的方式。我的公司有 100 多个表，我的老板给了我一个 ERD，用于所有连接的特定集合表。因此，您可能还想尝试将 1 个大型 ERD 分解为一组更小的、可管理的 ERD。
如果向最终用户描述您的数据库是您的主要目标，那么 Ooluk 数据字典管理器可以证明是有用的。它是一个基于 Web 的多用户软件，允许您将描述附加到表和列，并允许对这些描述进行全文搜索。它还允许您使用标签对表进行逻辑分组，并使用这些标签浏览表。可以标记表和列以在您的数据库中查找相似的数据项。
该软件允许您使用 API 将元数据信息（例如表名、列名、列数据类型、外键）导入其内部存储库。对 JDBC 数据源的支持是内置的，并且可以进一步扩展，因为 API 源在 ASL 2.0 下分发。它被编码为从许多 RDBMS 中读取 COMMENTS/REMARKS。您始终可以手动覆盖导入的信息。可以使用自定义字段扩展您可以存储的有关表和列的信息。
数据字典管理器使用“数据对象”和“属性”术语而不是表和列，因为它不是专门为关系数据库设计的。
笔记
披露：我在开发该产品的公司工作。
好吧，一张图片说明一千个单词，所以我建议创建 ER 图，您可以在其中一目了然地查看表之间的关系，这是纯文本描述很难做到的。
您不必在一个图表中完成整个数据库，将其分解为多个部分。我们在工作中使用 Visual Paradigm，但 EA 和 ERWIN 一样是一个不错的选择，毫无疑问还有很多其他的也一样好。
如果您有耐心，那么使用 html 来记录表格和列会使您的文档更易于访问。