从前，DBA是IT环境中无可争议的司法官，但近年来却变得越来越不受欢迎，特别是在当前所谓的“shadow IT”时代里（译者注：shadow IT指在企业IT部门以外所发生的技术投入和部署，包括个别员工、团队和业务部门所采用的云应用程序）。有些人把敏捷开发模型和网络应用程序与Wild West的数据集作比较，这些有着结构化数据和非结构化数据的数据集如雨后春笋般遍布整个企业。
在没有DBA管控的情况下，开发人员进行应用开发会产生许多问题，集中体现在新一代IT数据孤岛以及过分复杂的系统方面。这是一个异常严峻的挑战。其中，Gartnet预测道，到了2017年，因缺少应有的有效信息治理政策和规划，存放于NoSQL数据库中50%的数据将会对相应业务造成不良影响。
但可悲的是，DBA建议关注的问题和试图增加的管理流程，往往会拖慢构建应用的过程。以西部牛仔打个比方，DBA就像那个不受欢迎的陌生人，所有人都会阻止他步入酒吧，隐瞒他所做的一切。
或者我说得有点夸张，因为应用开发和DBA之间的关系还没有恶化到那种地步。但如果要试图恢复IT环境秩序，将会是一个艰苦卓绝的挑战。
流程 vs 敏捷
DBA一直有责任维护和组织周边的数据流动，保持其稳定性和完整性。但是在Hadoop和NoSQL的炒作达到了白热化阶段，人们似乎产生了一种错觉，认为比起工作流程，IT部门更应该向业务部门展示他们是如何做到快速响应和敏捷开发的。
虽然NoSQL解决方法可能在某些情况下非常理想，但是它的部署需要被规划和管理。
例如，NoSQL数据库没有ACID原则。某些人声称ACID原则只存在一个文档里面，但企业内部通常要求不同数据集之间要保持数据完整性，这就需要开发复杂的应用程序去挑起重担，而关系型数据库一早就已经可以实现。
NoSQL解决方案只存储数据，不处理数据。数据必须由应用程序加以分析。而应用程序（因此每个应用程序开发人员）有责任保持数据的高效访问，以实现业务规则和数据一致性。
这对他们来说太过复杂，因为每个NoSQL数据库产品使用不同的数据表现方式以及不同的数据访问/操纵语句。所以，组织往往会发现他们拥有多个并不兼容的NoSQL解决方案。
NoSQL解决方案不能支持存储过程，并且不能代表任何一个单独的技术，它妨碍了应用代码的重用、标准建立以及多样功能的资源发现。最后，只使用NoSQL方案的企业会遇到更多的数据烟囱问题，因为每个应用都要求使用自己的数据集，导致企业数据更碎片化并疏于治理。
Postgres在NoSQL上的扩展
这是在制造会产生严重后果的后续问题。在英国，当监管机构应对重大IT系统故障时，我们已经看到过这些问题的发生。
幸运的是，在Postgres，有一个技术解决方案，有助于长远解决这些问题。例如，你可以用关系表关联非结构化数据，所有的这些都将保持ACID原则，以及建立在集中化业务处理规则和逻辑的基础上。
支持JSON、JSONB，处理文档型数据，以及Key/value键值对的Hstore数据类型，Postgres能提供灵活的数据建模能力，开发人员可以构建一个适应业务目标变化的应用程序。
Postgres也允许开发者在SQL语句中直接使用JSON文档，完成大批量的JSON数据操作以及与关系型数据的来回转换。建立非结构化数据集以及与关系型表中快速结合组件的能力，是关系型数据库前所未有的重大创新。
Postgres支持非结构化的数据集，但另一方面也允许开发者根据业务需求应用选择数据的模式和规则。使用外部数据封装，开发人员可以在Postgres集成外部的结构化和非结构化数据，并使Postgres能用SQL查询和读写外部数据源。这些外部数据封装，支持mongoDB、 couchDB、MySQL、Redis、Neo4j甚至Twitter等。
最后，我强调一点。与shadow IT集成不单纯是一个技术问题，尽管我认为Postgres上的创新对避免系统复杂性和数据孤岛有很大的帮助。
但是，我们也必须要避免企业的IT环境最后演变成“OK镇大决斗”（译者注：美国电影，形容突如其来的小规模枪战/殴斗）。无论是应用开发还是DBA团队，都应该紧密合作，共同努力，保证IT是保持企业竞争优势和支持业务战略的关键。
（新炬网络梁铭图翻译，DAMS整理成文，架构师联盟微信号：jiagoushi2015）
扫码关注
获取峰会最新信息