超越模型的益处
将语义上结构化的数据和一些像超链接、文本、图片以及音频片段的东西结合起来的一个主要原因是创建更为丰富的用户体验。对消费者来说，这是必须的，而不是可选的。对你雇佣的知识型工作人员而言，这会使他们做事更有效率。只有对从事日常管理的员工来说，它才会成为一种障碍。然而你应用SOA越多，你对这些人员的需要就越少。他们从表单键入数据的工作可以外包给任何人做：你需要做的仅仅是扫描每个表单然后把图像发送给代理，代理本质上使用和用户一样的Web表单去键入数据。至少真正需要雇员日常处理的工作都可以用自动化完成。
不要让自己禁锢于数据库数据的第二大原因是，把数据库化和基于文本的数据结合起来是目前维持营运合规所需记录信息和审计线索最简单的方法。数据库因其特有的性质并不适合这样的最终目的。因为通常某个数据库是为担当某种管理现状模型而构建的，所以当该管理现状改变的时候，它应该很容易去做相应改变。数据库管理系统就是为了方便这种改变而设计的。当它们被用来维护不允许被更改的记录时——比如，簿记条目——设计者不得不把各种安全防御构建到系统中，从而防止对记录的恶意操作。即便如此，神智清醒的外行人也不会去信任数据库的。为营运合规目的需要的记录信息和审计线索必须被委托给记录管理程序，然后通过SOA来与数据库系统进行关联。
使用SOA，把语义结构化的数据和其他形式的信息表示连接起来很容易。这使得它是内容管理和内容表示的理想之选。数据库可以将超链接保存到其他信息中。比如，我们可以用交易的数据库记录来存储产生该交易的输入文档的超链接。当显示交易记录的同时，链接也跟着展现，而且可以让使用者通过单独的服务去激活它。开发一个使其能够从归档文件去访问文档的服务不会比开发一个从数据库访问数据的服务更困难。当然了，除非你的归档文件不具有SOA能力，此时第一件要做的事情就是替换掉它。
但是，反过来也一样。不仅语义格式化的数据通过链接来丰富记录，而且记录也可以通过链接来丰富语义格式化数据。当你将记录存储于归档文件中的时候，与记录相关的语义结构化数据通常会包含所有为其索引而需要的信息。几乎不可能不需要手工索引记录。可喜的是，每当交易在数据库中进行一次，索引就可以自动对其更新从而逐步丰富起来。
集成数据库化和基于文档的数据有另一大优点，就是很容易支持数据的多个版本。在数据库世界这是说不通的，因为数据库作为一种模型，且作为一种有用的模型，它必须在对管理现状模型的任何提问作出至少一个最佳的猜测以应答。一个文档，实际是某个特定组织在特定时间以及特定环境所做的一个声明，而且这也很有可能——经常被用来了解——相冲突声明的存在。
文化冲击
请注意，数据库化的思考者不是唯一在统一文档和数据库世界遭遇困难的人。那些思维方式受当代文档和记录管理系统影响的人会遇到更大的困难。一时之间，归档文件成为业务流程的一部分，而不是流程完成后形成。而索引不是人工完成，也不是一个文档一个索引，而是自动并持续更新的。索引也不再是归档的一部分：归档仅仅只包含文件，而索引分开维护。因此不需要把自己局限于一个归档，或者只局限于你自己的归档。这些改变是如此深远，很难想象那些适应了旧世界的人也能对新世界适应。
8.不要使用快照模型
具体而正式的历史信息
我职业生涯中最大的错误就是设计了这样的数据库，其中所有服务请求都被给予一个时间戳，以便数据添加进去后，服务可以根据指定时刻数据库存放的数据内容来响应，而不是根据当前内容。这个数据库极其昂贵，把执行速度拖累得就像龟行，而且没能起到很大作用。当用户想看看过去某个特定的结果是怎么被计算出来的时候，他们不免只能够查询归档文件，因为这些归档文件总是会包含之前与用户沟通的结果。而这也正是他们想要知道的东西。
请注意数据库的用途不是去记录过去那些成为问题的情况。数据库是现实世界某些部分的模型，以及在过去某一段时间里现实世界那部分的状态——它的具体历史——可能和模型的目的非常相关。但是，如果它想要再现自己在过去某个点的状态，换句话说去记录它的正式历史信息，数据库就太把自己当回事儿了。
喜欢 
顶
难过
囧
围观
无聊
