摘要：本文回顾了数据库与SQL最初的目的与其中包含的架构思想，分析了数据库平台在应用架构发展中的退化问题以及数据库为中心或面向数据库的架构。面向数据库与面向服务架构 (SOA)，似乎是矛盾的：一个向前，一个向后。但在更深入的层次上，是可以实质地结合或统一的。
数据库的初衷是直接面对最终用户
关系数据库和SQL最初提出时，都含有直接针对最终的用户，而不是软件开发者或作为软件间的接口的意思。将数据集中、专门管理，然后让最终用户如同到银行存钱、取钱一样使用，这是数据库之父 E. F. Codd 最初的想法，所以他初次发表时使用的名字，正是“数据银行”(data bank)。这里包含着这样一些意思：
- 用户既取（查询、输出）、也存（创建、修改、删除）；
- 数据是独立的（存在银行或仓库这一事实不代表其所有权的转移）；
- 数据库及其操作是内容无关的（无论存取何种货币或者货品，银行、货仓的设施、基本手续是一样的）；
- 操作简易、通用（例如屏蔽了存放、处置、保护钱的各种麻烦）。
透过早期的dBase产品，也能体验到这种想法，及渐渐演变的过程。现在的DBMS产品概念，基本已经是纯粹的“后台”，而SQL也几乎完全成为嵌入在高级程序代码中，供程序员使用的一种中间语言，甚至就连定位为终端用户桌面产品的MS-Access这样的特殊产品，也很少为最终用户直接使用。
数据库平台在应用架构发展中的退化
以前，我留意到许多程序员在设计数据库应用时，不使用数据库平台的基本特性，例如存储过程、触发器，CHECK、DEFAULT、NOT NULL、UNIQUE，甚至连FOREIGN KEY，PRIMARY KEY都不用。那时感觉有一部分人这样做是出于对数据库的理解不够。但除去这一部分，也有很多实在的理由，比如跨平台的需要等等。按照现在的主流技术，中间层不仅已经成为常态，而且成为另一个可由通用商业平台支撑下的层次（应用服务器），这个层次看来似乎大有夺走数据库的“逻辑层”基本功能的趋势。按照这种趋势，数据库平台基本就只发挥其“物理层”的功能：存储、快速检索数据。这种趋势，与商业数据库产品发展过程中拼命加厚后台功能（例如后台过程编程的能力）的趋势，是有矛盾的。数据库平台、应用平台之间，面临着一次功能的重分配或定位。
以数据库为中心的应用与面向数据库
无论技术架构的层次分工上怎样变化，有一个基本点是不会变化的，即涉及到企业基本业务的综合企业应用系统，是建立在“信息”（大量有意义的数据）基础上的，在这个背景下，“企业应用”与“企业信息系统”几乎同义。这是由企业本身的特质决定的，应用系统架构只能顺应它。
从这个角度再去观察，各种企业应用（不论管理信息系统MIS、企业资源规划系统ERP，还是事务处理系统TPS或决策支持DSS，甚至业务智能BI、知识管理km），都是“基于数据库”的。假设一个企业从不同的公司购买了若干不同的应用，按照现在的状况，几乎可以肯定，它们各自的数据库都是独立的。涉及这个问题的流行说法是信息孤岛，其实每个信息孤岛覆盖面的重叠隐藏着更大的问题。把这样的东西集成起来，哪怕用上最新的SOA架构，也只是掩盖而不是解决问题的根本。站在用户的立场上，这些数据本来就是一个关联的整体。现在没有一种方案或技术能帮助现实中的企业达成这种理想的状态，但这个道理是很重要的，不应忽视。
退一步说，企业应用开发者至少应该理解，数据本来不应该是属于特定的应用软件，而是属于用户。应该假设先有用户的数据——客观存在的、整体的、自我演化中的——应用开发者是做一些工具去操作这些数据。这样一种观念，称为“以数据库为中心”(Database-Centered)，从系统分析与实现的逻辑或系统架构上说，即“面向数据库”(Database-Oriented)。不管以往的应用开发者主观意识是否这样认为，客观地看，这是大部分企业应用（或许可以笼统地归纳为企业信息系统应用）都具有或隐含着的一个特征。
面向数据库，与当前兴起的面向服务架构 (SOA)，似乎是矛盾的：一个向前，一个向后。但我看它们在更深入的层次上，是可以实质地结合或统一的。与面向数据库相对照，现在绝大多数的企业应用设计者的思维是“面向功能”的，或者说是前台功能导向的。将这些思路对比思考一下，可能会是很有启发的。
原始发表：flyingrobot, 2007-09-28,
https://blog.csdn.net/flyingrobot/article/details/1804688
作者印记：c8cc97
