在转到奥尔胡斯，我们对NoSQL的一些实际经历进行了一条轨道。我被要求发出初步谈谈，以解释NoSQL数据存储的基本原则。我谈论NoSQL，NoSQL数据模型的形式的起源，许多NoSQL数据库考虑一致性问题的方式，以及PolyGlot持久性的重要性。

近年来，关于无模式数据的优点的讨论越来越多。无模式是感兴趣的主要原因之一NoSQL数据库．但是，在数据库和内存中数据结构方面，无模式性涉及许多微妙之处。这些微妙之处体现在无模式的含义和使用无模式方法的优点和缺点上。

当我们设计了这本书时，NoSQL蒸馏，我们在大部分章节的结尾都总结了一些要点，作为重读这本书的人的复习。我们在网站上列出了这些内容，作为读者提醒自己注意这些要点的另一种方式。

其中一个曲目转到奥尔胡斯让NoSQL供应商有机会谈论他们的各种工具。在曲目结束时，不同的演讲者被安排到一个小组讨论一些涉及NoSQL的共同问题。虽然我没有参加比赛(我的演讲几天后出现了）我参与了小组。

我们在2012年伦敦QCon上的主题演讲着眼于数据在我们生活中所扮演的角色(并且它所做的不仅仅是变得更大)。我们先来看看数据世界是如何变化的:它正在成长，变得更加分散和联系。接下来我们来看看行业的反应:NoSQL的兴起、向服务集成的转变、事件来源的出现、云的影响以及可视化发挥更大作用的新分析。我们快速浏览一下现在数据是如何被使用的，Rebecca特别强调了发展中国家的数据。最后，我们考虑所有这些对于我们作为软件专业人员的个人责任意味着什么。

企业中数据存储未来的INFOCECK，主要用于参与应用程序开发管理的人。解释为什么关系数据库是主导的，为什么NoSQL挑战这种假设并勾勒出多胶持久性的未来，其中多个数据存储技术将根据其不同的需求用于应用。

这是我们在工作中最先想到的话题之一nosql蒸馏NoSQL数据库使用不同于关系模型的数据模型。我看过的大多数数据源都至少提到了四组数据模型:键值、文档、列族和图。看看这个列表，前三个之间有一个很大的相似之处——它们都有一个基本的存储单元，它是一个紧密相关的数据的丰富结构:对于键值存储它是值，对于文档存储它是文档，而对于列族存储它是列族。在DDD术语中，这组数据是ddd_aggregate．

几年前，我听到编程语言人们用由Java引起的语言谈论“核冬季”。这种感觉是每个人都融合在Java的计算模型上（C＃在那个点看起来不仅仅是一个撕裂的点），编程语言的创造力已经消失。这种感觉现在正在减弱，但也许更重要的解冻，可能开始 - 更长，更深入地思考数据库。

最近我看到越来越多的JSON数据结构通过服务器。JSON文档可以通过使用embetorientedDatabase.或者序列化LOB在关系数据库中。JSON文档还可以直接提供给web浏览器，或用于将数据传输到服务器端页面渲染器。当JSON以这种方式使用时，我听到有人说使用面向对象语言会碍事，因为需要将JSON转换成对象，然后再次呈现——这是对编程工作的浪费。我同意浪费的观点，但我认为这不是对象的问题，而是无法理解封装的问题。

在许多组织中，预计任何持久数据都将存储在由中央数据库管理组管理的关系数据库中。这种中央控制有各种原因，通常以使用为中心IntegrationDatabases．中央数据组担心遵循畸形的数据，可以减慢重要共享资源的查询，以及整个企业的一致数据模型。

值得这些目标可能是，但它们的后果是关于存储数据的相当大仪式。我经常听到有关更改周数的申诉，以将列添加到数据库中。对于现代应用开发商，习惯了短暂的进化设计，这种仪式太慢，更不用说太烦人了。

所以应用程序开发小组告诉我如何使用NoSQL数据库绕过dba进行一次终端运行。他们在这里使用的是“纯粹的数据存储”，而不是“正确的数据库”，这是有帮助的。通过这种方式，dba可以被排除在循环之外，通常不会被告知或乐于忽略。

我们开始工作nosql蒸馏我们面临着一个棘手的难题 - 我们写的是什么？什么是nosql数据库？那里没有强大的概念定义，没有商标，没有标准组，甚至没有宣言。

2006年，我的同事尼尔福特创造了这个词polyglot编程，表达应用程序应该用一种语言编写的想法，以利用不同语言适合解决不同问题的事实。复杂的应用程序结合了不同类型的问题，因此挑选了作业的正确语言可能比尝试将所有方面放入单一语言更高。

在过去的几年里，人们对新语言的兴趣激增，特别是函数式语言，我经常忍不住花些时间钻研Clojure、Scala、Erlang或类似的语言。但我的时间有限，我要优先考虑另一个更重要的转变，那就是Databasethaw.．最初的点滴来自客户和其他联系人，前景是诱人的。我可以自信地说，如果您开始一个新的战略性企业应用程序，您不应该再假定您的持久性应该是关系的。关系可能是正确的选择——但你应该认真考虑其他选择。