如何logging数据库
（注：我意识到这与您如何logging数据库结构很接近，但我不认为它是完全相同的。）
我已经开始在一个拥有数百个表和视图的数据库的地方工作，所有的名字都只有很less的元音，而且没有文档。 他们也不允许对数据库模式进行无端的更改，也不能在我自己的机器上触摸除testing数据库以外的任何数据库（这些数据库会被定期刷新并重新创build），所以我不能添加任何有助于任何人的注释。
我尝试使用“蟾蜍”创build一个ER图，但离开它跑了48小时后，它仍然没有产生任何可见的，我需要我的电脑回来。 我正在和其他一些最近的雇员谈话，我们都build议，无论什么时候我们困惑了一个特定的表或者它的某些列的含义，我们应该在开发者wiki中更新它。
那么做这个的好方法是什么？ 只要列出表格/视图及其列，并填写它们，我们去吗？ 我需要掌握的基本工具是Toad，Oracle的“SQL Developer”，MS Office和Visio。
根据我的经验，ER（或UML）图并不是最有用的工件 – 大量的表格，图表（特别是反向工程图）通常是一个没有人从中学到任何东西的大混乱的混乱。
为了我的钱，一些很好的人类可读的文件（可能补充了系统的较小部分的图表）将给你最多的里程。 这将包括，为每个表：
- 表格的含义及其在function上的用法（在用户界面等）
- 如果不明显，则说明每个属性的含义
- 从这张表到其他的关系的解释（外键），反之亦然
- 附加约束和/或触发器的解释
- 如果他们没有很好地logging，主要视图和触摸表的附加解释
有了以上所有的内容，为了logging的目的，不要使用文档 – 重申明显的文档只是以人为本。 相反，把注意力放在首先让你困惑的东西上，花几分钟写出真正清晰，简明的解释。 这会帮助你思考，而且会大大帮助其他开发者第一次碰到这些表。
正如其他人所提到的，有很多种工具可以帮助您pipe理这些工具，比如Enterprise Architect ， Red Gate SQL Doc以及来自不同供应商的内置工具。 但是，虽然工具支持是有益的（甚至在更大的数据库中是关键的），但是理解和解释数据库概念模型的努力是真正的胜利。 从这个angular度来看，你甚至可以在一个文本文件中做这件事（尽pipe以Wiki的forms做这件事可以让几个人合作，逐步增加这个文档 – 所以，每当有人找出某个东西的时候，他们可以把它添加到不断增长的身体的文件立即）。
我们使用Enterprise Architect来进行数据库定义。 我们包含存储过程，触发器和UML中定义的所有表定义。 该计划的三大亮点是：
- 从ODBC连接导入UML图。
- 一次为整个数据库生成SQL脚本（DDL）
- 生成您的数据库的自定义模板化文档。
您可以在UML工具中编辑您的类/表定义，并使用包含图片的文档生成完整的描述。 自动生成的文档可以是多种格式，包括MSWord。 在我们的模式中，我们只有不到100个表格，而且相当pipe理。
作为一名开发人员，我从未在10多年里对其他任何工具印象深刻。 EA一举支持Oracle，MySQL，SQL Server（多个版本），PostGreSQL，Interbase，DB2和Access。 任何时候遇到问题，他们的论坛都会及时回答我的问题。 强烈推荐！！
当数据库更改进来时，我们在EA中创buildSQL，并将其检入到我们的版本控制（svn）中。 我们使用Hudson进行构build，当它看到您修改了签入的sql时，它会从脚本自动构build数据库。
（ 大部分是从我的另一个答案中被窃取的 ）
在我们的团队中，我们find了有用的方法来logging传统的大型Oracle和SQL Server数据库。 我们使用Dataedo来logging数据库模式元素（数据字典）并创buildERD图表。 Dataedo附带文档资源库，因此您所有的团队都可以在线logging和阅读最近的文档。 而且您不需要干涉数据库（Oracle注释或SQL Server MS_Description）。
首先你导入模式（所有表，视图，存储过程和函数 – 触发器，外键等）。 然后定义逻辑域/模块并将所有对象（拖放）分组到其中，以便能够分析和处理较小的数据库块。 对于每个模块，您创build一个ERD图并编写顶级描述。 然后，当你发现表和视图的含义时，为每个表写一个简短的描述。 每列都做同样的事情。 Dataedo使您能够为每个对象和列添加有意义的标题 – 如果对象名称模糊或无效，则非常有用。 Pro版本使您能够描述外键，唯一键/约束和触发器 – 这对于理解数据库是有用但不重要的。
您可以通过UI访问文档，也可以将其导出为PDF或交互式HTML（后者仅在专业版中可用）。
这里描述的是一个连续的过程，而不是一次性的工作。 如果数据库发生更改（例如新列，视图），则应定期同步文档（与Dataedo单击几次）。
请参阅示例文档： http : //dataedo.com/download/Dataedo%20repository.pdf
关于文件处理的一些准则：
图：
- 保持你的图表小而易读 – 只包括重要的表格，关系和栏目 – 只有那些对大局有所了解的人 – 主要/商业关键，重要的属性和关系，
- 对图表中的关键表使用不同的颜色，
- 每个模块可以有多个图表，
- 您可以添加图表来描述最重要的表格/大部分关系。
说明：
- 不要logging明显 – 不要写document.date列的描述“文档date”。 如果没有什么意义的添加只是留下空白，
- 如果存储在表中的对象具有types或状态，则可以将它们列在表的一般描述中，
- 定义预期的格式，例如。 “mm / dd / yy”表示存储在文本字段中的date，
- 列出所有已知/重要的值，例如状态列可以是这样的：“文档状态：A-活动，C-取消，D-删除”，
- 如果表中有任何API – 应该用于读取数据和函数/过程来插入/更新数据的视图 – 将其列在表的描述中，
- 描述行/列的值来自哪里（过程，表单，接口等），
- 对不应使用的列（标题列对此有用，请在说明字段中说明应使用哪个字段）使用“[deprecated]”标记（或类似标记）。
有一点需要考虑的是DBMS中内置的COMMENT工具。 如果您对DBMS中的所有表和所有列进行注释，那么您的文档将在数据库系统内。
使用COMMENT工具不会对模式本身进行任何更改，只会将数据添加到USER_TAB_COMMENTS目录表中。
这个答案延伸了Kieveli的上面，我赞成。 如果您的EA版本支持对象angular色build模（概念devise，逻辑devise= ERD），请反向工程，然后用丰富的performance填充模型。
便宜和重量轻的选项是从MS免费下载Visiomodeler，并做同样的事情。
ORM（称为ORMDB）是我所发现的唯一支持和鼓励与非信息系统利益相关者就BL对象和关系进行数据库devise对话的工具。
现实检查 – 在生成DDL的过程中，它会经过一个完整的ERD阶段，在这个阶段你可以满足你是否有任何扭曲的问题。 它不。 它可能会显示你自己devise的ERD的弱点。
ORMDB是一个经典案例，越是概念化的工具，市场越小。 女孩只是想玩，程序员只是想编码。
这里有一篇关于如何处理数据库文档的好文章： http : //www.simple-talk.com/sql/database-administration/database-documentation–lands-of-trolls-why-and-how/
维基解决scheme支持超链接和协作编辑，但维基只是维持其组织和最新的人才。 无论您使用什么工具，您都需要有人来承担文档项目的所有权。 这个人可能会涉及其他有知识的人来填写细节，但是一个人应该负责组织信息。
如果您不能使用工具通过逆向工程生成ERD，则必须使用TOAD或VISIO手动devise一个工具。
任何带有数百个对象的ERD对于开发人员来说可能是没有用的，因为这么多盒子和线条都无法读取。 在拥有如此多对象的数据库中，很可能存在几十个表和视图的“子系统”。 所以你应该制定这些子系统的自定义图表，而不是期待一个工具来为你做。
您也可以devise一个伪ERD，其中一组表在一个图中由单个对象表示，而该组在另一个图中展开。
一个单一的ERD或一套ERD不足以logging这个复杂的系统，不仅仅是一个类图就足以logging一个面向对象的系统。 你必须写一个文件，使用ERD作为插图。 您需要对每个表，每列以及表之间的关系（特别是在这些关系是隐含的而不是由参照完整性约束表示的情况下）的含义和使用进行文本描述。
所有这些都是很多工作，但是这是值得的。 如果有一个清晰，最新的模式logging的地方，整个团队将从中受益。
既然你有与同舟共济的开发者共事的奢侈，那么我会build议问他们最容易传达什么信息。 我的公司有超过100张桌子，而我的老板给了我一个所有连接的特定设置表的ERD。 所以你也可以尝试把一个庞大的ERD分解成一堆小的，可pipe理的ERD。
如果描述你的数据库到你的最终用户是你的首要目标， Ooluk Data Dictionary Manager可以certificate是有用的。 这是一个基于networking的多用户软件，允许您将描述附加到表格和列上，并允许在这些描述上进行全文search。 它还允许您使用标签对表格进行逻辑分组，并使用这些标签浏览表格。 可以对表和列进行标记，以便在数据库/数据库中查找相似的数据项。
该软件允许您使用API将元数据信息（例如表名，列名，列数据types，外键）导入到其内部存储库中。 对JDBC数据源的支持是内置的，并且可以进一步扩展，因为API源是在ASL 2.0下分发的。 它被编码为从许多RDBMS中读取COMMENTS / REMARKS。您可以随时手动覆盖导入的信息。 您可以存储有关表格和列的信息可以使用自定义字段进行扩展。
数据字典pipe理器使用“数据对象”和“属性”术语而不是表和列，因为它不是专门为关系数据库devise的。
笔记
- 如果描述你的数据库的技术方面，如触发器，索引，统计是重要的，这个软件不是最好的select。 然而，使用超链接自定义字段可以将技术解决scheme与此软件相结合。
- 该软件不会产生ERD
披露：我在开发这个产品的公司工作。
那么，一张图片就能说出千言万语，所以我build议您创build一个ER图表，在这里您可以一目了然地查看表格之间的关系，这是一个很难处理纯文本描述的问题。
您不必在一个图表中完成整个数据库，将其分解为多个部分。 我们在工作中使用Visual Paradigm，但EA和ERWIN一样是一个很好的select，毫无疑问，还有很多其他的一样好。
如果您有足够的耐心，那么使用html来logging表格和列会使您的文档更容易访问。
