什么样的ERP架构思想才是正确的
企业软件热点文章 商业智能系统中应该支持多种数据源 满足管理三重属性 ERP发展专业化是方向 由于国内企业实施ERP/SCM的时间较外国企业晚,对于ERP/SCM企业资源整合全面电算化的经验和专业应用上普遍都较欧美企业晚起步二十年以上.因此,有许多MIS和经营管理咨询公司的专业从业人员都可能会误认为:'欧,美,日国家的ERP/SCM企业资源整合全面电算化的专业技术肯定比国内先进,完美!'.这个想法也许可以被容许,但是却不是绝对正确的看法.罗马帝国发展得比美国还早N千年,如果照前面这个道理推理的话,美国的科技永远都赶不上罗马帝国,这个误解能称得上是个道理吗?先做的人不必然做得更好,慢做的人也未必然做得不好,巧思妙用完全存乎于不同专业人才的脑海构思规划里,谁家天下则是自有安排. 首先说个简单的故事:有一天早上,一辆载满货物的卡车冲进了遂道,由于高度超过了遂道高度,卡车的前半身卡在遂道里,后半身则露在遂道外头,进退不得,卡车司机没有受伤,可是却把整个遂道堵得水泄不通,绵延了数公里的车队.交警找来了各种车辆协助将卡车拉出遂道,来来回回三,四个小时都无功而返,周边围了四,五百人看得膛目结舌,就是拿不出一个法子.突然一个七岁的孩子走到这个地方围观,他开口说:'就把卡车的所有轮胎泄了气,卡车就不会卡住遂道了,不是吗?',结果众人一试,卡车轮胎泄了气,就少了近40公分的高度,果真卡车就顺利拉出来了!如果你说:'我吃的盐巴比你吃的饭还多上千百倍!',这个只有倚老卖老的人才会有这么个无知的说法,所谓:'后生可愄',这个肯定是个平凡的道理. 如果你具备一定的经营管理专业知识,有相当年资的软件规划和开发的实务经验,加上在制造产业实际辅导ERP全面电算化实施的经验,你将能够轻易的发现,目前国内、外很多ERP软件系统规划的架构理念是有严重的错误的,一套良好的ERP系统不仅仅是功能要完整,整合程度要高,运行效率要快,实施过程要短,必须具备QRM快速反应机制,维护作业要简单,移植能力要好,还要实质上能大幅降低营运成本.可是,当你使用过国内、外ERP软件,你会发觉,这些ERP的最终的诉求,他们大部份都无法实现. 举个案例来说:国外软件在系统架构上,将所有关系企业的数据都存放在同一个数据库Database里,光是这个规划方式,就是一个非常严重的错误.我们把几个问题范例给予提列出来:1.多家关系企业的数据都存放在同一个数据库,把没有任何关系的数据存放在一起,系统执行的速度肯定会变得更慢,这已经违反了ERP提高工作效率的原则.从10,000笔资料中查找一笔符合条件的资料,和在100,000笔资料中查找一笔符合条件的数据,你认为不会影响速度吗?将一个公司过期的ERP资料结转到历史文件,和将十个公司过期的ERP数据结转到历史文件,所使用的时间会是一样的吗?一套好的ERP软件系统的使用量是非常惊人的,每个User占用Data server或AP server的时间越长,就表示电脑提供服务的时间就越久,运行的效率就越差.对于只有白天上班的企业来说,其利用下班时间来处理大量的批次过档数据,可能还有相当充裕的时间,可是对于24小时轮班的企业而言,晚上时间还有大量的电脑用户在执行工作,如果要将多家关系企业的大批量过期资料结转到历史档中,这就会严重的干扰到其他User的工作执行.这个和单独将一家企业的过期资料结转到历史档中所需要耗费的时间和速度是非常不一样的. 2.任何一种ERP的资料Table,在每一家关系企业,都有不同的属性或用途,例如:料品主档,相同的一个料品,在AX01公司属于原材料,在BL01公司属于半成品,在DX03公司属于制成品,在FC02公司则是属于商品,到底由哪家公司的人来负责定义这个属性?为甚么别人公司的数据要由某个人来统一设定呢?另外,属于研发机能的属性该由谁来设定?属于采购机能的属性该由谁来设定?属于生产机能的属性该由谁来设定?属于营业机能的属性该由谁来设定?属于委外加工机能的属性该由谁来设定?属于生管机能的属性该由谁来设定?属于物控机能的属性该由谁来设定?属于财务和成本属性的数据该由谁来设定?本来各公司自行设定,既快速,又简洁,现在把它搞在同一个Database,就变得复杂无比,每建立一个新的产品,就可能有几十项到几百,几千项新的子阶料品,就需要等待这些料品都建立完毕,才能开始顺利运作,这算是有效率的管理模式吗?为了每一个关系企业而设定的不同属性的数据,能够放在同一个Table里定义吗?10个公司的属性和50个公司的属性,如果存放在一起,字段数量肯定不同,因此,肯定必须放在不同的Table里,这就让系统的复杂度变大了,如果有30个关系企业,对于不同的属性数据,就必须开30个Table,在系统的维护工作上,不就变得非常复杂了吗?一个人有一个头,一个身体,两条胳膊,两条腿,五脏六府......,这是何等的灵活而有效率,现在把30个人的头,身体,胳膊,两条腿,五脏六府......等等全部结合在一起,这个架构能够更有效率的运行吗?从30个合倂的人体中让其中一个人运作...
软件架构的视图
我们决定以多种构架视图来表示软件构架。
每种构架视图针对于开发流程中的涉众(例如最终用户、设计人员、管理人员、系统工程师、维护人员等)所关注的特定方面。
构架视图显示了软件构架如何分解为构件,以及构件如何由连接器连接来产生有用的形式 [PW92],由此记录主要的结构设计决策。
这些设计决策必须基于需求以及功能、补充和其他方面的约束。
而这些决策又会在较低层次上为需求和将来的设计决策施加进一步的约束。
构架由许多不同的构架视图来表示,这些视图本质上是以图形方式来摘要说明“在构架方面具有重要意义”的模型元素。
在 Rational Unified Process 中,您将从一个典型的视图集开始,该视图集称为“4+1 视图模型”[KRU95]。
它包括:用例视图:包括用例和场景,这些用例和场景包括在构架方面具有重要意义的行为、类或技术风险。
它是用例模型的子集。
逻辑视图:包括最重要的设计类、从这些设计类到包和子系统的组织形式,以及从这些包和子系统到层的组织形式。
它还包括一些用例实现。
它是设计模型的子集。
实施视图:包括实施模型及其从模块到包和层的组织形式的概览。
同时还描述了将逻辑视图中的包和类向实施视图中的包和模块分配的情况。
它是实施模型的子集。
进程视图:包括所涉及任务(进程和线程)的描述,它们的交互和配置,以及将设计对象和类向任务的分配情况。
只有在系统具有很高程度的并行时,才需要该视图。
在 Rational Unified Process 中,它是设计模型的子集。
配置视图:包括对最典型的平台配置的各种物理节点的描述以及将任务(来自进程视图)向物理节点分配的情况。
只有在分布式系统中才需要该视图。
它是部署模型的一个子集。
构架视图记录在软件构架文档中。
您可以构建其他视图来表达需要特别关注的不同方面:用户界面视图、安全视图、数据视图等等。
对于简单系统,可以省略 4+1 视图模型中的一些视图。
【系统架构和软件架构】正交软件架构方法
果你想要制作易于设计、构建、测试及扩展的系统,正交性是一个十分关键的概念,但是,正交性的概念很少被直接讲授,而常常是你学习的各种其他方法和技术的隐含特性。
这是一个错误。
一旦你学会了直接应用正交性原则,你将发现,你制作的系统的质量立刻就得到了提高。
什么是正交性 文本框: “正交性”是从几何学中借来的术语。
如果两条直线相交成直角,它们就是正交的,比如图中的坐标轴。
用向量术语说,这两条直线互不依赖。
沿着某一条直线移动,你投影到另一条直线上的位置不变。
在计算技术中,该术语用于表示某种不相依赖性或是解耦性。
如果两个或更多事物中的一个发生变化,不会影响其他事物,这些事物就是正交的。
在设计良好的系统中,数据库代码与用户界面是正交的:你可以改动界面,而不影响数据库;更换数据库,而不用改动界面。
在我们考察正交系统的好处之前,让我们先看一看非正交系统。
非正交系统 你正乘坐直升机游览科罗拉多大峡谷,驾驶员——他显然犯了一个错误,在吃鱼,他的午餐——突然呻吟起来,晕了过去。
幸运的是,他把你留在了离地面100英尺的地方。
你推断,升降杆控制总升力,所以轻轻将其压低可以让直升机平缓降向地面。
然而,当你这样做时,却发现生活并非那么简单。
直升机的鼻子向下,开始向左盘旋下降。
突然间你发现,你驾驶的这个系统,所有的控制输入都有次级效应。
压低左手的操作杆,你需要补偿性地向后移动右手柄,并踩右踏板。
但这些改变中的每一项都会再次影响所有其他的控制。
突然间,你在用一个让人难以置信的复杂系统玩杂耍,其中每一项改变都会影响所有其他的输入。
你的工作负担异常巨大:你的手脚在不停地移动,试图平衡所有交互影响的力量。
直升机的各个控制器断然不是正交的。
正交的好处 如直升机的例子所阐明的,非正交系统的改变与控制更复杂是其固有的性质。
当任何系统的各组件互相高度依赖时,就不再有局部修正(local fix)这样的事情。
提示13 Eliminate Effects Between Unrelated Things 消除无关事物之间的影响 我们想要设计自足(self-contained)的组件:独立,具有单一、良好定义的目的(Yourdon和Constantine称之为内聚(cohesion)[YC86])。
如果组件是相互隔离的,你就知道你能够改变其中之一,而不用担心其余组件。
只要你不改变组件的外部接口,你就可以放心:你不会造成波及整个系统的问题。
如果你编写正交的系统,你得到两个主要好处:提高生产率与降低风险。
提高生产率 l 改动得以局部化,所以开发时间和测试时间得以降低。
与编写单个的大块代码相比,编写多个相对较小的、自足的组件更为容易。
你可以设计、编写简单的组件,对其进行单元测试,然后把它们忘掉——当你增加新代码时,无须不断改动已有的代码。
l 正交的途径还能够促进复用。
如果组件具有明确而具体的、良好定义的责任,就可以用其最初的实现者未曾想象过的方式,把它们与新组件组合在一起。
l 如果你对正交的组件进行组合,生产率会有相当微妙的提高。
假定某个组件做M件事情,而另一个组件做N件事情。
如果它们是正交的,而你把它们组合在一起,结果就能做M x N件事情。
但是,如果这两个组件是非正交的,它们就会重叠,结果能做的事情就更少。
通过组合正交的组件,你的每一份努力都能得到更多的功能。
降低风险 正交的途径能降低任何开发中固有的风险。
l 有问题的代码区域被隔离开来。
如果某个模块有毛病,它不大可能把病症扩散到系统的其余部分。
要把它切掉,换成健康的新模块也更容易。
l 所得系统更健壮。
对特定区域做出小的改动与修正,你所导致的任何问题都将局限在该区域中。
l 正交系统很可能能得到更好的测试,因为设计测试、并针对其组件运行测试更容易。
l 你不会与特定的供应商、产品、或是平台紧绑在一起,因为与这些第三方组件的接口将被隔离在全部开发的较小部分中。
让我们看一看在工作中应用正交原则的几种方式。
项目团队 你是否注意到,有些项目团队很有效率,每个人都知道要做什么,并全力做出贡献,而另一些团队的成员却老是在争吵,而且好像无法避免互相妨碍? 这常常是一个正交性问题。
如果团队的组织有许多重叠,各个成员就会对责任感到困惑。
每一次改动都需要整个团队开一次会,因为他们中的任何一个人都可能受到影响。
怎样把团队划分为责任得到了良好定义的小组,并使重叠降至最低呢?没有简单的答案。
这部分地取决于项目本身,以及你对可能变动的区域的分析。
这还取决于你可以得到的人员。
我们的偏好是从使基础设施与应用分离开始。
每个主要的基础设施组件(数据库、通信接口、中间件层,等等)有自己的子团队。
如果应用功能的划分显而易见,那就照此划分。
然后我们考察我们现有的(或计划有的)人员,并对分组进行相应的调整。
你可以对项目团队的正交性进行非正式的衡量。
只要看一看,在讨论每个所需改动时需要涉及多少人。
人数越多,团队的正交性就越差。
显然,正交的团队效率也更高(尽管如此,我们也鼓励子团队不断地相互交流)。
希望能帮到你,麻烦点击 好评,...
用什么工具画 软件架构设计图
UIDesigner是腾讯用户研究与体验设计部(CDC)设计研发的一款设计类软件,打造一款可以让设计师统一平台和团队协作的平台型设计工具,经过1.0和2.0版本的经验沉淀,我们决定对3.0版本进行全新的架构设计。
开发一个软件系统,前期的架构设计承载着整个软件的设计思想和关键决策,可以说是重中之重。
根据软件架构设计思想,关注分割和交互,好的架构必须使每个关注点相互分离。
我们进行了最基本的需求分析,得出两个关注点:一是工具,二是设计绘图,关系如图1所示。
得到最基本的两个关注点后,接着将提取关键需求(包括:关键功能需求、关键质量需求和关键商业需求),根据两个关注点进行架构的细化设计。
一、关注点——工具这里我们结合UIDesigner的实际需求,提取出属于“工具”范畴的关键功能需求、关键质量需求和关键商业需求。
首先,“工具”的关键功能需求,必须包括:磁盘文件读写、异常捕捉、日志记录、安全性管理;非工具所必须,但是UIDesigner本身所要求的,包括:配置管理、缓存管理、线程服务、服务器和客户端通讯管理、国际化服务。
其次,“工具”的关键质量需求,质量需求包括开发期质量需求和运行期质量需求两部分,经过分析和权衡,UIDesigner的性能主要取决于设计绘图,而稳定性、可扩展性和可维护性才是决定“工具”本身发展的质量需求,因此,对“工具”的质量需求设计将以稳定性、可扩展性和可维护性为主。
最后,“工具”的关键商业需求,因为UIDesigner本身并没有很复杂的业务需求,因此关键商业需求是在设计流程的优化和规范上得到体现,这方面的设计已经属于高层模块和使用流程的设计,对架构的影响非常小,可以暂时性的忽略。
经过关键需求的提取,我们得到了“工具”的设计目标——可以提供通用功能(关键功能需求)的高稳定性、扩展性和维护性的客户端应用。
根据此目标,我们采取了DI(Dependency-Injection)和MVP(Model-View-Presenter)结合的架构,概念架构设计如图2所示。
软件架构模式基本概念及三者区别
在做软件架构设计时,根据不同的抽象层次可分为三种不同层次的模式:架构模式(Architectural Pattern)、设计模式(Design Pattern)、代码模式(Coding Pattern)。
架构模式是一个系统的高层次策略,涉及到大尺度的组件以及整体性质和力学。
架构模式的好坏可以影响到总体布局和框架性结构。
设计模式是中等尺度的结构策略。
这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。
模式的好坏不会影响到系统的总体布局和总体框架。
设计模式定义出子系统或组件的微观结构。
代码模式(或成例)是特定的范例和与特定语言有关的编程技巧。
代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节,但不会影响到一个部件或子系统的中等尺度的结构,更不会影响到系统的总体布局和大尺度框架。
架构模式(Architectural Pattern)一个架构模式描述软件系统里的基本的结构组织或纲要。
架构模式提供一些事先定义好的子系统,指定它们的责任,并给出把它们组织在一起的法则和指南。
称之为系统模式。
?MVC模式,一个架构模式常常可以分解成很多个设计模式的联合使用。
MVC模式常常包括调停者(Mediator)模式、策略(Strategy)模式、合成(Composite)模式、观察者(Observer)模式等。
?Layers(分层)模式,有时也称Tiers模式?Blackboard(黑板)模式?Broker(中介)模式?Distributed Process(分散过程)模式?Microkernel(微核)模式架构模式常常划分成如下的几种:一、 模块结构(From Mud to Structure)型。
帮助架构师将系统合理划分,避免形成一个对象的海洋。
包括Layers(分层)模式、Blackboard(黑板)模式、Pipes/Filters(管道/过滤器)模式等。
二、分散系统(Distributed Systems)型。
为分散式系统提供完整的架构设计,包括像Broker(中介)模式等。
三、人机互动(Interactive Systems)型,支持包含有人机互动介面的系统的架构设计,例子包括MVC(Model-View-Controller)模式、PAC(Presentation-Abstraction-Control)模式等。
四、Adaptable Systems型,支持应用系统适应技术的变化、软件功能需求的变化。
如Reflection(反射)模式、Microkernel(微核)模式等。
设计模式(Design Pattern)一个设计模式提供一种提炼子系统或软件系统中的组件的,或者它们之间的关系的纲要设计。
设计模式描述普遍存在的在相互通讯的组件中重复出现的结构,这种结构解决在一定的背景中的具有一般性的设计问题。
设计模式常常划分成不同的种类,常见的种类有:创建型设计模式,如工厂方法(Factory Method)模式、抽象工厂(Abstract Factory)模式、原型(Prototype)模式、单例(Singleton)模式,建造(Builder)模式等结构型设计模式,如合成(Composite)模式、装饰(Decorator)模式、代理(Proxy)模式、享元(Flyweight)模式、门面(Facade)模式、桥梁(Bridge)模式等行为型模式,如模版方法(Template Method)模式、观察者(Observer)模式、迭代子(Iterator)模式、责任链(Chain of Responsibility)模式、备忘录(Memento)模式、命令(Command)模式、状态(State)模式、访问者(Visitor)模式等等。
以上是三种经典类型,实际上还有很多其他的类型,比如Fundamental型、Partition型,Relation型等等。
设计模式在特定的编程语言中实现的时候,常常会用到代码模式。
比如单例(Singleton)模式的实现常常涉及到双检锁(Double-Check Locking)模式等。
代码模式(Coding Pattern)代码模式(或成例)是较低层次的模式,并与编程语言密切相关。
代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。
较为著名的代码模式的例子包括双检锁(Double-Check Locking)模式等
软件架构设计和企业架构模式之间的关系是什么?
一般而言,架构有两个要素:它是一个软件系统从整体到部分的最高层次的划分。
一个系统通常是由元件组成的,而这些元件如何形成、相互之间如何发生作用,则是关于这个系统本身结构的重要信息。
详细地说,就是要包括架构元件(Architecture Component)、联结器(Connector)、任务流(Task-flow)。
所谓架构元素,也就是组成系统的核心"砖瓦",而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果,任务流则描述系统如何使用这些元件和联结器完成某一项需求。
建造一个系统所作出的最高层次的、以后难以更改的,商业的和技术的决定。
在建造一个系统之前会有很多的重要决定需要事先作出,而一旦系统开始进行详细设计甚至建造,这些决定就很难更改甚至无法更改。
显然,这样的决定必定是有关系统设计成败的最重要决定,必须经过非常慎重的研究和考察。
计算机软件的历史开始于五十年代,历史非常短暂,而相比之下建筑工程则从石器时代就开始了,人类在几千年的建筑设计实践中积累了大量的经验和教训。
建筑设计基本上包含两点,一是建筑风格,二是建筑模式。
独特的建筑风格和恰当选择的建筑模式,可以使一个独一无二。
正如同软件本身有其要达到的目标一样,架构设计要达到的目标是什么呢?一般而言,软件架构设计要达到如下的目标:·可靠性(Reliable)。
软件系统对于用户的商业经营和管理来说极为重要,因此软件系统必须非常可靠。
·安全行(Secure)。
软件系统所承担的交易的商业价值极高,系统的安全性非常重要。
·可扩展性(Scalable)。
软件必须能够在用户的使用率、用户的数目增加很快的情况下,保持合理的性能。
只有这样,才能适应用户的市场扩展得可能性。
·可定制化(Customizable)。
同样的一套软件,可以根据客户群的不同和市场需求的变化进行调整。
·可扩展性(Extensible)。
在新技术出现的时候,一个软件系统应当允许导入新技术,从而对现有系统进行功能和性能的扩展
安卓软件架构是指什么
第一、什么是C/S结构。
C/S(Client/Server)结构,即大家熟知的客户机和服务器结构。
它是软件系统体系结构,通过它可以充分利用两端硬件环境的优势,将任务合理分配到Client端和Server端来实现,降低了系统的通讯开销。
目前大多数应用软件系统都是Client/Server形式的两层结构,由于现在的软件应用系统正在向分布式的Web应用发展,Web和Client/Server应用都可以进行同样的业务处理,应用不同的模块共享逻辑组件;因此,内部的和外部的用户都可以访问新的和现有的应用系统,通过现有应用系统中的逻辑可以扩展出新的应用系统。
这也就是目前应用系统的发展方向。
传统的C/S体系结构虽然采用的是开放模式,但这只是系统开发一级的开放性,在特定的应用中无论是Client端还是Server端都还需要特定的软件支持。
由于没能提供用户真正期望的开放环境,C/S结构的软件需要针对不同的操作系统系统开发不同版本的软件,加之产品的更新换代十分快,已经很难适应百台电脑以上局域网用户同时使用。
而且代价高,效率低。
第二、什么是B/S结构。
B/S(Browser/Server)结构即浏览器和服务器结构。
它是随着Internet技术的兴起,对C/S结构的一种变化或者改进的结构。
在这种结构下,用户工作界面是通过WWW浏览器来实现,极少部分事务逻辑在前端(Browser)实现,但是主要事务逻辑在服务器端(Server)实现,形成所谓三层3-tier结构。
这样就大大简化了客户端电脑载荷,减轻了系统维护与升级的成本和工作量,降低了用户的总体成本(TCO)。
以目前的技术看,局域网建立B/S结构的网络应用,并通过Internet/Intranet模式下数据库应用,相对易于把握、成本也是较低的。
它是一次性到位的开发,能实现不同的人员,从不同的地点,以不同的接入方式(比如LAN,WAN,Internet/Intranet等)访问和操作共同的数据库;它能有效地保护数据平台和管理访问权限,服务器数据库也很安全。
特别是在JAVA这样的跨平台语言出现之后,B/S架构管理软件更是方便、快捷、高效。
第三、管理软件主流技术。
管理软件技术的主流技术与管理思想一样,也经历了三个发展时期。
首先,界面技术从上世纪DOS字符界面到Windows图形界面(或图形用户界面GUI),直至Browser浏览器界面三个不同的发展时期。
其次,今天所有电脑的浏览器界面,不仅直观和易于使用,更主要的是基于浏览器平台的任何应用软件其风格都是一样的,使用人对操作培训的要求不高,而且软件可操作性强,易于识别;再者,平台体系结构也从过去单用户发展到今天的文件/服务器(F/S)体系、客户机/服务器(C/S)体系和浏览器/服务器(B/S)体系。
二、C/S和B/S之比较C/S和B/S是当今世界开发模式技术架构的两大主流技术。
C/S是美国Borland公司最早研发,B/S是美国微软公司研发。
目前,这两项技术以被世界各国所掌握,国内公司以C/S和B/S技术开发出产品也很多。
这两种技术都有自己一定的市场份额和客户群,各家企业都说自己的管理软件架构技术功能强大、先进、方便,都能举出各自的客户群体,都有一大群文人墨客为自己摇旗呐喊,广告满天飞,可谓仁者见仁,智者见智。
1、C/S架构软件的优势与劣势(1)、应用服务器运行数据负荷较轻。
最简单的C/S体系结构的数据库应用由两部分组成,即客户应用程序和数据库服务器程序。
二者可分别称为前台程序与后台程序。
运行数据库服务器程序的机器,也称为应用服务器。
一旦服务器程序被启动,就随时等待响应客户程序发来的请求;客户应用程序运行在用户自己的电脑上,对应于数据库服务器,可称为客户电脑,当需要对数据库中的数据进行任何操作时,客户程序就自动地寻找服务器程序,并向其发出请求,服务器程序根据预定的规则作出应答,送回结果,应用服务器运行数据负荷较轻。
(2)、数据的储存管理功能较为透明。
在数据库应用中,数据的储存管理功能,是由服务器程序和客户应用程序分别独立进行的,前台应用可以违反的规则,并且通常把那些不同的(不管是已知还是未知的)运行数据,在服务器程序中不集中实现,例如访问者的权限,编号可以重复、必须有客户才能建立定单这样的规则。
所有这些,对于工作在前台程序上的最终用户,是“透明”的,他们无须过问(通常也无法干涉)背后的过程,就可以完成自己的一切工作。
在客户服务器架构的应用中,前台程序不是非常“瘦小”,麻烦的事情都交给了服务器和网络。
在C/S体系的下,数据库不能真正成为公共、专业化的仓库,它受到独立的专门管理。
(3)、C/S架构的劣势是高昂的维护成本且投资大。
首先,采用C/S架构,要选择适当的数据库平台来实现数据库数据的真正“统一”,使分布于两地的数据同步完全交由数据库系统去管理,但逻辑上两地的操作者要直接访问同一个数据库才能有效实现,有这样一些问题,如果需要建立“实时”的数据同步,就必须在两地间建立实时的通讯连接,保持两地的数据库服务器在线运行,网络管理工作人员既要对服务器维护管理,又要对客户端维护和管理,这需要高昂的投资和复杂的技术支持,维护成本很高,维护任务量大。
...