经过多年的企业级相关开发，跟数据库的交道打得太多了。每个企业相关的项目都离不开数据库，尤其是Mis，Erp和一些报表等需要存储相关的，数据库是不二选择了。 从刚开始的拖拽控件，到慢慢学着封装，走了很长的路。越到后来，越是如履薄冰，因为跟数据库的耦合太紧，基本意味着设计过于依赖本来是帮助我们的存储介质。这显然是个度的把握。对什么事物过于依赖总不是好事。尤其数据库跟程序的依赖就是业务逻辑跟数据存储的依赖。虽然现在的oracle有了自己的Form builder， report等直接可以实现业务的工具。 但我认为这不见得是好事。我的看法一直是业务实现最好不要知道数据存在那里了，存给谁了， 只要知道交给谁去存就可以了。Xml的出现应该是个让人振奋的亮点。当然这个话题是比较大的，我要说的，只是其中相关的一点，很多时候我们可能只需要建立在某一种数据库之上构造我们的程序，或者某几种，又或者我们在将来的某个时间发现需要更换其他数据库来支持系统，又或者用户说我们必须更换数据库来适应他们的业务变化。如果们的程序只依赖在某个数据库上，那么麻烦就会来临。尤其是在系统中如果写 了很多Oracle或者Access或者其他某种数据库特有的SQL，而没有采用规范的处理。 下面的一些设计，或许会带来新的局面，当然应该有更高明的设计，也许不同的领域不同的需要有不同的设计方式。

         废话是需要说的，但是重点不是废话，下面是一张UML设计图：

         虚线左边是数据源管理部分，可以单独作为一个单元或者名称空间，只要单独提供一个IDBManage给外界（外界即，需要数据库连接的地方）就可以实现数据库的读写。虚线右边是提供具体的数据集，TOnsQuery是一个抽象的聚合了数据集的数据集类，它可以支配需要的具体数据集来完成数据处理，也可以通过TDB的派生类来完成对不同数据库类型的特殊SQL语句的处理。