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