如何潜入一个丑陋的数据库?

eie*_*fai 26 database-design

我相信你们中的许多人正在/正在处理一个丑陋的数据库。你知道,那个根本没有规范化的数据库,那个你必须进行大量痛苦的查询才能获得最琐碎的数据的数据库,那个正在生产中的数据库,你不能改变一点......你知道, “那个”。

我的问题是,如何处理的?

  • 你尝试创建一个新的数据库吗?
  • 你放弃并留下它吗?
  • 你能给出什么建议?

Bil*_*win 29

  • 我做的第一件事是创建一个实体关系图(ERD)。有时您可以使用命令行工具简单地描述元数据,但为了节省时间,有一些工具可以自动生成图表。

  • 其次,检查每个表和列,确保我了解它存储的内容的含义。

  • 第三,检查每个关系并确保我理解这些表格之间的关系。

  • 第四,阅读任何视图或触发器以了解自定义数据完整性实施或级联操作。

  • 第五,读取任何存储过程。如果有,还要读取 SQL 访问权限。

  • 第六,通读使用数据库的部分应用程序代码。这就是执行一些附加业务规则和数据完整性规则的地方。


更新: 我刚刚阅读了一篇有趣的文章“继承数据库时要做的 9 件事”,其中有一个很好的清单。

概括:

  1. 备份
  2. 研究(我上面提到的模式文档步骤)
  3. 与前开发人员交谈
  4. 一个错误数据库
  5. 源代码控制
  6. 与用户和/或企业主交谈
  7. 通过修复一些事情或进行一些改进,在用户中建立信誉
  8. 创建开发环境
  9. 删除过时的对象


Mil*_*s D 13

这并不总是可能的,但在某些情况下对我有用的一件事是用视图替换某些表。然后您可以整理下面的表格,并在某些情况下最终处理视图。正如我所说,仅在某些情况下有效。


Con*_*lls 9

数据字典是你的朋友。此外,尝试使用 Visio 上的逆向工程工具对数据库进行逆向工程,并构建您自己的一组图表。因为逆向工程是交互式的——你构建图表——它比阅读数据字典更具吸引力。这个过程的积极性是它的优势,我觉得这样做很放松。

我所做的大部分工作都在数据仓库中,其中探索源系统数据库模式是一项核心活动。我已经在很多场合做过这种事情,并且发现它的效果非常好。

Visio pro 并不昂贵,而且 Visio 建模引擎可让您在多个图表之间共享一个模型。作为奖励,您可以在图表中添加缺少的外键,并最终获得一组有用的系统文档。


小智 6

我为供应商的软件处理了一个非常丑陋的问题,除了提出建议之外,我无法对其进行太多更改。我一直在努力改变事情,但由于它超出了我的控制范围,我被困在垃圾中。

由于数据库完全没有关系,我很快开始使用的一件事是模式的通用名称查询:

--Find Column named like 'blah' in a specific table
SELECT O.NAME, O.ID, C.NAME, O.XTYPE
FROM SYSOBJECTS O LEFT JOIN SYSCOLUMNS C ON O.ID=C.ID
WHERE C.NAME LIKE '%SearchFor%' AND O.XTYPE IN ('U','V') AND O.Name like '%TableName%'
ORDER by O.Name
Run Code Online (Sandbox Code Playgroud)

或者

--Find all Columns in DB with name like 'blah'    
SELECT O.NAME, O.ID, C.NAME, O.XTYPE
FROM SYSOBJECTS O LEFT JOIN SYSCOLUMNS C ON O.ID=C.ID
WHERE C.NAME LIKE '%SearchFor%' AND O.XTYPE IN ('U','V')
ORDER by O.Name
Run Code Online (Sandbox Code Playgroud)

由于某些表有太多名称不佳的列,并且有太多列无法查看以找到我可能能够用来形成表之间关系的内容。

我知道这对问题的重新设计部分没有多大帮助,但它对理解和破译错误模式非常有帮助。


小智 6

SchemaCrawler是我的数据库发现工具,它有几个功能可以轻松探索丑陋的数据库。SchemaCrawler 具有类似“grep”的功能,允许您使用正则表达式搜索表和列。例如,您可以搜索名称中包含“ACCOUNT”的表和列,它们可能以某种方式相关。

SchemaCrawler 还会推断外键关系,即使在没有外键的情况下也是如此。它通过使用常见命名约定查找“弱关联”来实现这一点,例如表名通常是复数,但列名不是,并且列名可能有前缀 _ID。您可以使用这些推断的关系找到相关表。


小智 6

除了 Bill Karwin 的想法之外,我还建议与用户交谈 - 有时用户对他们的数据库的用途有相当多的了解,尤其是当他们从数据库中进行任何报告时。


Ano*_*nJr 5

取决于它的丑陋程度,以及您对设计的控制程度以及与之交互的内容。多年来,我在目前的工作中不得不与许多丑陋的数据库进行交互,以下是我处理它们的方式:

员工数据

有保存员工数据的数据库。它是一个供应商数据库,所以我无法控制它。(联合国?)幸运的是,我无法直接访问它。我每天早上都会收到 DTS 转储。

我能够管理的最好的方法是编写一个脚本,从早上转储中清理输入(是的,这个词的选择是有意的)并将其迁移到更有用的格式,并从清理过的数据中工作。

即使我可以改变它,我也可能不会——只是因为有大量其他程序依赖于它的设置方式,我不能强制改变它们。

在线训练数据

这是我自己设计的一团糟。我刚从大学毕业就在没有导师帮助的情况下构建了它......从那以后我一直在修复它。由于我控制访问数据的唯一程序,因此当我升级站点的某些部分时,我将“升级”数据库的配置。我将编写一个转换脚本并在副本上对其进行大力测试,以便确保完成所有需要进行的更改。

这是一个漫长的过程,但进展顺利。

课堂训练数据

我的试点项目一直在整合来自 3 个不同数据库的数据,所有数据库的设计都与我的前任略有不同……他是一名上过一两节编程课的护士教育者。

这是另一个缓慢的过程。因为我可以完全控制访问数据的程序,所以我一直在像在线培训数据一样一点一点地改变它。

回想起来,这本来是开始干净的主要候选人......事后看来总是20/20。

到底...

我不知道这有多大帮助,我可以详细说明(在某种程度上,公司法律 yada yada 等等)。最终答案是“视情况而定”。


gar*_*rik 5

由于外部应用程序使用它,您无法更改数据库“接口”。我不知道您使用的是什么类型的数据库(oracle、mysql、mssql),但我认为这是一种方法:

  • 使用诸如视图和存储过程等类型的对象来构建数据库接口。
  • 逐步重构(规范化,字段重命名...)
  • 更改客户的应用程序(如果需要)

视图、存储过程会隐藏内部数据库的修改(更改)。


eie*_*fai 5

所以在阅读了你所有的答案后,我给你我的:

首先我查找“主表”,然后用笔和纸,开始映射与其他表的关系,之后,如果有一些应用程序代码要查看,我开始绘制一些关于数据如何流动的原始草图。

在我对 db 如何工作有了一个很好的了解后,我开始检查可以改变事物的地方。就是这样。

我不知道为什么,但我更喜欢纸而不是任何数据库建模软件。