(注意:我意识到这很接近你如何记录你的数据库结构?但我不认为它是相同的.)
我已经开始在一个拥有数百个表和视图的数据库的地方工作,所有这些都使用含有非常少的元音的神秘名称,而且没有文档.他们也不允许对数据库模式进行无偿更改,也不能触摸除我自己的机器上的测试数据库之外的任何数据库(它会被吹走并定期重新创建),因此我无法添加可以帮助任何人的注释.
我尝试使用"Toad"来创建一个ER图,但是在让它连续运行48小时之后它仍然没有产生任何可见的东西,我需要我的电脑.我正在和其他一些最近招聘的人员谈话,我们都建议每当我们弄清楚某个特定表格或其中某些列的含义时,我们应该在开发人员维基中更新它.
那么有什么好办法呢?只需列出表格/视图及其列,并在我们去的时候填写它们?我必须掌握的基本工具是Toad,Oracle的"SQL Developer",MS Office和Visio.
根据我的经验,ER(或UML)图表并不是最有用的工件 - 大量的表格,图表(尤其是逆向工程图表)往往是一个很大的错综复杂的混乱,没有人从中学到任何东西.
对于我的钱,一些好的人类可读文档(可能补充了系统较小部分的图表)将给你最大的里程.这将包括,对于每个表:
表格的含义以及功能如何使用(在UI中等)
每个属性的含义的描述,如果不明显的话
从该表到其他人的关系(外键)的解释,反之亦然
附加约束和/或触发器的解释
如果他们没有很好地记录,那么触及表格的主要观点和触发的附加说明
综上所述,不要为了记录而记录文档 - 重述明显的文档只是以人的方式进行.相反,首先关注那些困扰你的东西,并花几分钟时间写出清晰简洁的解释.这将帮助你思考它,它将大大帮助其他第一次遇到这些表格的开发人员.
正如其他人所提到的,有很多工具可以帮助您管理这些工具,例如Enterprise Architect,Red Gate SQL Doc以及来自不同供应商的内置工具.但是,虽然工具支持是有用的(甚至是更重要的,在更大的数据库中),但是理解和解释数据库概念模型的艰苦工作才是真正的胜利.从这个角度来看,你甚至可以在一个文本文件中做到这一点(尽管在Wiki表单中进行这项工作可以让几个人合作逐步添加到那些文档中 - 所以,每当有人想出某些东西时,他们就可以将它添加到不断增长的身体中立即文件).
需要考虑的一件事是建立在DBMS中的COMMENT工具.如果您对DBMS本身中的所有表和所有列添加注释,那么您的文档将位于数据库系统中.
使用COMMENT工具不会对架构本身进行任何更改,它只会将数据添加到USER_TAB_COMMENTS目录表中.
我们使用Enterprise Architect作为数据库定义.我们包括存储过程,触发器和UML中定义的所有表定义.该计划的三大亮点是:
从ODBC连接导入UML图.
立即为整个DB生成SQL脚本(DDL)
生成数据库的自定义模板文档.
您可以在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使您可以为每个对象和列添加有意义的标题 - 如果对象名称含糊或无效,则它很有用.Pro版本使您能够描述外键,唯一键/约束和触发器 - 这对于理解数据库很有用但不是必需的.
您可以通过UI访问文档,也可以将其导出为PDF或交互式HTML(后者仅在Pro版本中可用).
这里描述的是一个连续的过程,而不是一次性的工作.如果您的数据库发生更改(例如,新列,视图),您应定期同步文档(使用Dataedo进行几次点击).
请参阅示例文档:http: //dataedo.com/download/Dataedo%20repository.pdf
关于文件处理的一些准则:
图:
保持您的图表小巧可读 - 只需包含重要的表格,关系和列 - 只有具有任何意义才能理解大图 - 主要/业务键,重要属性和关系,
对图表中的关键表使用不同的颜色,
每个模块可以有多个图表,
您可以将图表添加到最重要的表/最关系的描述中.
说明:
不要记录显而易见的事项 - 不要为document.date列写下描述"文档日期".如果添加没有任何意义,请将其留空,
如果存储在表中的对象具有类型或状态,最好将它们列在表的一般描述中,
定义预期的格式,例如."mm/dd/yy"表示存储在文本字段中的日期,
列出所有已知/重要值及其含义,例如状态列可能是这样的:"文档状态:A - 活动,C - 已取消,D - 已删除",
如果表中有任何API - 应该用于读取数据的视图和插入/更新数据的函数/过程 - 将其列在表的描述中,
描述行/列的值来自何处(过程,表单,接口等),
对不应使用的列使用"[deprecated]"标记(或类似)(标题列对此有用,请在说明字段中说明应使用哪个字段).