ACM通信
数据库衰退和如何应对
图片来源:麻省理工学院计算机科学与人工智能实验室
设计数据库模式的传统方法是使用设计工具(通常基于UML或ER模型)为数据构造初始数据模型。当一个人对结果满意时，工具将自动构造一个3的集合理查德·道金斯模型的范式关系。然后，根据这个关系模式对应用程序进行编码。当业务环境发生变化时(它们经常发生变化)，应该再次运行该工具以生成新的数据模型和新的结果表集合。从旧模式填充新模式，并修改应用程序以在新模式上工作，尽可能使用关系视图以简化迁移。通过这种方式，数据库保留在3中理查德·道金斯标准形式，它代表着DBMS研究人员定义的“好的”模式。“在野外”，模式通常每季度或更频繁地更改一次，传统的方法是对每个更改重复上述操作。
在对波士顿地区三家大型公司的20名数据库管理员(dba)的调查中，我们发现，对于大型的多部门应用程序，这种传统智慧几乎从未被遵循。相反，dba非常努力地在业务条件发生变化时不更改模式，而倾向于在不更改模式的情况下“使事情正常工作”。如果必须更改模式，则直接从现有的关系表开始工作。使用这些策略，ER或UML模型(如果它曾经存在过的话)会迅速脱离现实。而且，随着时间的推移，数据的实际语义会越来越偏离3理查德·道金斯标准表单数据模型。
我们称之为现实与3的背离理查德·道金斯标准形式的原则数据库衰变．随着时间的推移，腐烂变得越来越严重，导致腐烂的数据库，最终到那些已经退化到无法进一步修改的数据库。显然，这是一种非常不可取的状态。
在我们看来，衰退的原因源于大型实现的多部门组织。因此，整个应用程序的各个部分由不同的组织编码，通常使用ODBC或JDBC指定事务中的SQL。如果一个业务单元需要更改数据库的语义，那么就很难弄清楚需要更改来自其他部门的哪些代码以及所需的修复范围有多大。在我们看来，这导致dba更改模式的方式使应用程序维护最小化，而不是进行更改以使数据的清洁度最大化。当然，不同的DBA成本函数的结果是数据库衰减和腐烂。
似乎，数据库衰退是不可避免的事实，它最终导致数据库无法修改。有三种策略可以对抗数据库衰退。
第一个是构造防御模式首先。这种模式比使用传统智慧产生的模式更能适应随后的变化。我们已经为这种模式开发了一种方法，这将在接下来的一篇论文中讨论。
第二个策略是写作防御应用程序代码．例如，永远不应该使用Select * From Table-name，因为如果向下添加或删除属性，它往往会使应用程序中断。
最后，在我们看来，让应用程序组直接针对ODBC/JDBC接口编写代码是一个糟糕的实践。这就是dba不知道可能的模式更改的影响的原因。相反，我们主张要求应用程序组使用消息传递接口向DBMS发送高级命令。这些消息被拦截，并在服务器端代码中转换为SQL。这样的体系结构本地化了DBMS代码，这些代码可能在以后需要更改。此外，我们已经编写了一个原型系统，它可以检查这样的代码，并确定它是否需要作为模式演进的结果进行更改。通过这种方式，我们希望降低模式更改的成本，并可能减缓或阻止数据库衰退。即将发表的一篇论文详细介绍了我们的原型。
我们正在寻找“在野外”的数据库项目，这些项目处理的是模式进化，可以尝试我们的原型系统。如果你有兴趣，请联系Michael Brodiemlbrodie@mit.edu．
迈克尔Stonebraker是麻省理工学院计算机科学和人工智能实验室(CSAIL)的兼职教授，2014年ACM A.M.图灵奖。迈克尔·布罗迪是CSAIL的研究附属机构，而邓董而且劳尔•卡斯特罗费尔南德斯博士后研究员。
没有发现记录