3
是否采用C/S体系结构的讨论
3.1 当前确定的需求
在这个案例中，已经确定的需求，就是建立一个集中、统一的数据库，实现更新、查询和格式化打印输出操作。访问者分布在总公司（约30人的规模，集中办公，连结于一个小型的LAN中）和外地的子公司（同样是集中办公，连结于一个比总公司大的LAN中）。每一处典型的同时访问人数，在10人以下。两处都有机会更新数据库中的数据。理想的情况下当然是两处的数据随时保持一致，但在特别关键的信息可以随时通过电话、传真等方式直接交换的情况下，两地的信息每隔一至二天交换更新一次，是可以接受的，这也就是目前的实际情况，从业务人员的立场上，尚没有提出在这个周期上作出戏剧性的改变的要求。针对当前的已经明确的需求，作出如下讨论：
采用C/S架构，选择适当的数据库平台，可以实现数据库数据的真正"统一"，分布于两地的数据同步完全交由数据库系统去管理，逻辑上，两地的操作者都直接访问同一个数据库。它的有效实现，有这样一些问题：
如果需要建立"实时"的数据同步，就必须在两地间建立实时的通讯连接，保持两地的数据库服务器在线运行，这需要高昂的投资和复杂的技术支持，高的维护成本。
可以根据实际的需要，采用"间歇"同步策略，通过合理分配两地的工作（这一点是现实业务中已经很好地实现的），基本可以避免分别更新数据可能对业务带来的问题。对数据库同步更新的间隔，可以天为最小单位，在这样的同步需求下，采用复杂和昂贵的"分布式数据库"管理技术[注1]，是不划算的。
在该案例中，当前需求的一个重要特征，是在LAN中的多用户操作。进一步分析该客户的要求可以得知，数据更新的频率是很低和集中于少数用户的。大量可能的并发性操作来自查询。
对于本例的应用要求和环境，采用基于网络文件服务器开发非C/S结构的应用，也完全可以满足，虽然C/S结构下的多用户应用可以更好（比如更完善的用户共享特性，用户管理，以及更好地平衡服务器与客户机之间的负荷，大幅度降低网络传输的负荷等），但就用户立场而言，并没有采用C/S结构直接的必要性。
[注1]：应当说明，对于其他的架构的数据库体系，同样可以实现分布式的数据存储与管理，但从本例实现的角度看，比起基于C/S架构的体系，要复杂和昂贵。
|
