高手啊高手，你在哪里？ ---- 多层应用问题 (100分)

由于正版数据库系统的购买力问题及用户连接数限制，兄
弟想尽可能使用免费提供的“本地数据库”系统作为多层应用中的数
据库服务器，所以向各位同仁请教几个问题。
先说一下我的想法（假设现在有两台机器A、B，A是客户端，
B是LIBS服务器）：
1、A不直接访问B中的数据库，也不关心数据库的成分（类型），
它只向B中的代理程序（假设就叫 TMyDocumentProvider 吧）请求数据，
TMyDocumentProvider 向A提供数据。但数据的提交格式不再是表，比如
是一个 TRemoteDataList ，A接受到 TRemoteDataList 后就可以脱离
数据库的要求而直接用列表性操作来操作数据了；当A提交数据时，也
用TRemoteDataList来提交，B处理TRemoteDataList，并实现真正的提交。
2、如果A中有SQL语句，则由B将该SQL转换成本地SQL操作（LIBS），
数据返回如前。
3、TMyDocumentProvider 最好能提供数据缓存功能。以适应多方
请求（有点象MTS，但不需要那么复杂，而且数据返回处理也尽可能象
Delphi 中的 TList，让我只要 for 一下就可以了，呵呵）。
借用VC中的CDocument类，简单地讲，就是View(客户端)操作
CDocument，CDocument负责数据串行化（提交）。不过要把这种思想放到
多层应用中去。对客户端而言，你永远都看不到数据库，或者说根本就不
存在数据库，而只有 TStream，TMyDocumentProvider 提供数据的桥接功
能。这样，我就可以用本地数据库系统去做任何多层应用了。
但到底可行性或者性能会如何，想请教各位大侠，这样的想法
行不行得通？应该如何实现？在性能上会有什么影响？多用户同时连接时
会有什么问题？TMyDocumentProvider 编程工作量会不会很大？

用三层结构加上Pooler的使用就可以达到你的要求了。

使用 Database Pooling 必须在客户端进行 Client 配置。
我的意思是要完全消除 Client 端的数据库模式 ------
就象我们浏览 HTML 一样，有谁需要知道服务器用的是什么
数据库？

这个很容易实现啊！我是这样想的，你的客户端不要用sql.服务器端中提供datasetprovider
至于你用什么数据库与客户端没有一点关系。我现在的系统就是这样做的。

多人接受答案了。