以数据库为中心与面向数据库

数据库的初衷是直接面对最终用户

关系数据库和SQL最初提出时，都含有直接针对最终的用户，而不是软件开发者或作为软件间的接口的意思。将数据集中、专门管理，然后让最终用户如同到银行存钱、取钱一样使用，这是数据库之父E. F. Codd最初的想法，所以他初次发表时使用的名字，正是“数据银行”（data bank）。这里包含着这样一些意思：

1. 用户既取（查询、输出）、也存（创建、修改、删除）；
2. 数据是独立的（存在银行或仓库这一事实不代表其所有权的转移）；
3. 数据库及其操作是内容无关的（无论存取何种货币或者货品，银行、货仓的设施、基本手续是一样的）；
4. 操作简易、通用（例如屏蔽了存放、处置、保护钱的各种麻烦）。

透过早期的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年9月28日, 企业应用探索日志, http://blog.vsharing.com/flyingrobot