发挥人肉搜索引擎威力，大量MP悬赏，要求内详(发帖人MP:10652390)

建议你去电骡的软件或者教程之类的分栏搜搜~
中英文关键词搜索
应该有部分资料

www.emule.org.cn
www.verycd.com

帮顶一个下

专业性太强
而况其他系统的参数管理不见得可以做为借鉴
举个数据库的例子,数据流量的不同，一系列参数都不会相同,而且几乎没有可比性,就算是项目实施,也要不断的改进.

帮顶`

太专业了。。。
帮lz顶下

纯粹帮顶

太专业
帮顶~

我为MP 而顶你



　　　　　　　点击加入烟民社区
　　　　　　　点击使用社区称号
　　　　　　　点击进入官方论坛
　　　　　　　点击传呼联盟盟主

看来只能顶了

专业帮顶

着快速成型(Rap id P ro to typ ing: RP) 技术的不断发
展, 用户对RP 软件在数据处理的易用性、可靠性方面的要
求越来越高[1 ] , 因此, 管理大量的STL (RP 技术采用的准标
准模型文件格式) 模型、数据文件及各种工艺参数是必要的
前提。在研制台式低成本、小体积快速成型系统过程中设计
了参数管理数据库并与RP 软件系统进行了集成。对RP 中
的大量STL 模型及其相关参数进行科学管理有其必要性:
(1) 参数管理规范化
当模型较多时, 无论是有经验的操作者还是普通的用户,
经常都会因模型无序的放置, 大量文件的管理而增大工作量。
这不仅加大了平时文件管理及成型加工时参数设置的难度,
延长了加工前的准备时间, 而且造成了计算机存储空间的浪
费。通过建立参数模型数据库, 可一次性对与成型过程有关的
各方面的参数进行有效管理, 这样, 不仅克服了以上所述的现
象, 且便于以后的各种需求, 如查询、修改、加工等。
(2) 系统运作自动化
通常所需加工的模型都涉及较多的参数, 如模型信息、
加工信息等, 对于一般用户而言, 设置这些与加工有关的参
数较困难, 也较费时。如建立起参数管理数据库, 就不必人
工来设置加工参数, 而仅仅由程序直接调用数据库里存储
的参数, 从而减少人为出错的可能性, 降低对系统操作人员
的要求, 提高系统的自动化水平。
1　台式快速成型系统的参数管理数据库设计
1. 1　数据模型及其开发工具的选择
在设计数据库全局逻辑结构时采用当前应用最为广泛
且最成熟的关系模型。目前出现的关系数据库主要有桌面
数据库M icro soft A ccess,M icro soft V isual FoxP ro, Bo r2
land Paradox, Pow er Builder 及关系数据库服务器O racle,
SQL Server 等。
桌面数据库是专门为在个人计算机上运行而设计的,
其规模比关系数据库服务器小, 但其功能已足以满足本系
统开发的需求, 且具有开发成本低、开发周期短的优势, 因
此选择桌面数据库作为开发工具。而几种桌面数据库中,
M icro soft A ccess 由于其低层平台的优势, 以及强大的交互
性、通用性、集成性及网络功能已成为当今最流行的、用于
创建和维护关系数据库的优秀软件, 因此, 在开发参数管理
数据库时选用了A ccess 作为开发工具。

1. 2　台式快速成型系统参数管理数据库设计目标
用户可预先设定和保存工艺参数, 并存入数据库, 数据
库能自动记录该模型的编号、名称、尺寸、切片层数、层厚等
属性, 用户也可直接浏览数据库中的各种参数并做出修改;
加工时, 软件系统直接读取数据库中的成型工艺各参数, 这
样, 可实现多个零件的自动加工。
1. 3　参数管理数据库设计
为实现台式RP 软件系统能一次性提取STL 模型及其
它实体的特征属性存入数据库, 并使得用户可按多种索引进
行灵活、高效的查找。在设计台式RP 参数管理数据库时分为:
· 参数管理数据库概念模型及关系模型设计—— 选
择实体集并分析实体集间的关系; 分析属性和关系的约束
并将关系模式规范化。
· 参数管理数据库行为设计——设计数据库查询、事
务处理、报表处理等程序。
论文主要论述前者, 后者以前者为基础, 主要涉及到数
据库实际设计方面的工作。
1. 3. 1　概念模型设计
概念模型可以很容易地导出关系数据模型, 简化了逻
辑设计中由于需要考虑多种因素带来的复杂性, 数据库设
计时采用实体—— 联系模型(Ent ity2Relat ionsh ip model:
E2R 模型) , 它具有直观、自然、语义丰富的特点[2 ]。建立E2
R 模型的关键是正确划分实体—— 属性及实体间的联系。
台式RP 参数管理数据库的E2R 图如图1 所示。
图1　台式RP 参数管理数据库E2R 图
图1 中方框表示同类实体的集合—— 实体型, 椭圆框
表示实体的属性, 菱形框表示实体间的联系, 实体间的1: n
表示1 个STL 模型经过不同的切片处理后可得到多个不
同的数据文件,m : n 表示数据文件与成型工艺参数是多对
多的关系。
1. 3. 2　关系模型设计
从E2R 模型直接向关系数据库模式转换时会出现信
息冗余、修改异常及删除异常现象, 为消除这些异常需进行
关系分解, 即把关系的属性分开而产生两个新的关系模式。
分解过程遵循了以下分解方法:
设待分解的关系R 的模式为{X 1, X 2, Y43;, X n}, 分解后
的两个关系L 及T 的模式分别为{Y 1, Y 2, Y43;, Y k }和{Z 1,
Z 2, Y43;, Zm }。
(1) {X 1, X 2, Y43;, X n}= {Y 1, Y 2, Y43;, Y k }∪{Z 1, Z 2, Y43;,
Zm }。
(2) 关系L 中的元组是R 的元组在{Y 1, Y 2, Y43;, Y k}上的
投影。如R 中的两个不同元组在L 上的投影存在两个相同的
元组, 则在L 上的当前实例中每个元组只保留一个副本。
(3) 关系T 中的元组是R 的当前实例中的元组在属
性集{Z 1, Z 2, Y43;, Zm }上的投影。R 中的两不同元组在T 上
的投影有两相同元组时, 与2) 类似处理。
1. 3. 3　规范化处理
对关系模式运用规范化理论作进一步处理, 先确定关
系模式的数据依赖集, 逐一分析关系模式, 检查是否存在部
分函数依赖、传递依赖、多值依赖等, 以确定关系模式处于
第几模式, 本关系模式采用的是第三范式即3N F, 利用E2R
图转换规则, 台式RP 参数管理数据库的关系模式可见图
1。图1 中各实体及其联系的属性中, 模型文件名、切片名、
数据文件名、工艺规划名、成型工艺参数设置编号为主关键
字, 模型编号、模型文件名、文件大小、数据文件名为普通索
引。
2　参数管理数据库与软件系统的集成
2. 1　数据库访问技术的选择
目前常用的数据库访问技术主要有ODBC,OL E DB,
ADO ,DAO。
利用ODBC (Open Database Connect ivity) 技术使得程
序员从具体的DBM S 中解脱出来, 从而极大地减少了软件开
发的工作量, 缩短了开发周期, 提高了效率和软件的可靠性。
OL E (O bject L ink ing and Embedding ) DB 是基于
COM 接口的数据库开发技术, 它具有COM 模型的灵活
性、健壮性, 同时具有访问的快速性, 并且对关系数据库和
非关系数据库的访问接口是一致的, 是数据库开发技术的
主要发展方向[3 ]。
ADO (A ct iveX Data O bject) 是M icro soft 为最新和最
强大的数据访问范例OL E DB 而设计的, 是一个便于使用
的应用程序层接口。ADO 最主要的优点是易于使用、速度
快、内存支出少和磁盘遗迹小。ADO 是一座连接应用程序
和OL E DB 的桥梁。
DAO (Data A ccess O bject) 是一组M icro soft A ccessö
Jet 数据库引擎的(COM ) 自治接口。DAO 属于高层数据库
接口, 可直接与A ccessöJet 数据库对话。通过Jet 引擎,
DAO 也可以与其它数据库进行通信。

研制的台式快速成型系统是面向中小企业及科研院校
的小体积、低成本系统, 因此其软件系统必须具有通用性、
可移植性、系统稳定、快速访问等特点, 基于以上要求, 数据
库接口选择了OL E DB。各种数据库访问技术比较见表1。
表1　各种数据库访问技术比较
项　　目ODBC DAO OL E　DB ADO
面向对象特性不好好好很好
能否访问非关系型数据源不能不能能能
高层还是低层控制低层高层低层高层
性能好不好很好
代码数量多少多少
2. 2　用OL E DB 技术实现台式RP 参数管理数据库与软
件系统的集成
　图2　创建参数管理数据
　　　　库应用程序步骤
直接用OL E DB 的
对象和接口设计数据库
应用程序需要书写大量
的代码。为了简化程序设
计, 采用了A TL (A ct ive
Temp late L ibrary ) 设计
OL E DB 数据应用程序。
通过A TL 模板库可很容
易地把OL E DB 与M FC
结合起来, 使数据库的参数查询等复杂的编程得到简化。
M FC 提供的CO leDBReco rdV iew 类也可使得数据库的界
面设计得到简化。
创建台式RP 参数管理数据库应用程序的步骤见图2。
2. 3　工艺参数的自动设置
　图3　台式RP 集成软件
　　　　系统的运行流程
台式RP 参数管理数据
库是面向用户及台式RP 软
件系统的。用户可通过数据
库界面直接对数据库进行查
询、修改等操作, 同时面向台
式RP 软件系统, 为其提供数
据支持, 在加工过程中RP 软
件系统可后台调用数据库的
相关参数。集成后的软件系
统的运行流程见图3, 数据库
查询界面见图4。
2. 4　台式RP 系统参数管理数据库的应用
台式RP 系统加工零件时的流程见图5。集成软件系统
首先查询参数管理数据库中是否已有待加工零件的存储信
息, 如有, 则直接调用该零件的相关信息立即加工, 如无此
零件的存储信息, 则需从零件的CAD 模型开始, 经切片分
层、参数设定之后, 一方面把零件的加工信息存入参数管理
数据库, 待以后加工该零件或该类零件之用; 另一方面, 数
据驱动台式RP 成型机直接加工零件。加工出的原型经模
具制造形成产品, 检测合格后, 才能投入使用。否则, 需修改
相关数据重新加工。

顶起

太专业
帮顶~

帮顶 呵呵

路过......帮顶.混点MP换猫爪...

试试这个www.emule.org.cn

帮顶

顶上去

关人肉引擎啥事？

案例场景：每个系统都是从域建模入手设计，通过建模将业务需求转化为软件域范围的模型，本文以围绕一个模型实现该模型的基本功能：增删改查(CRUD)和批量分页查询，通过Jdon框架的迅速简化高质量的开发，建立一个复杂系统的基础部分，使得开发者将真正精力集中在每个项目系统的特殊业务处理。

　　源码见Jdon框架源码包中的Jdonsample项目。

　　案例需求：简单的留言簿，实现留言Message模型的新增、修改、删除和批量查询。

　　增删改查(CRUD)和批量分页查询是每个系统的基本功能，下面分这两部分描述。

　　CRUD开发步骤

　　说明：每个应用系统中存在大量重复的CRUD开发流程，通过本框架可快速完成这些基本基础工作量，将精力集中在特殊功能设计上。
CRUD快速开发主要简化了表现层的流程，将其固化，或者是模板化，以配置替代代码编制，灵活而快速。每个Model一套固化CRUD流程。
开发步骤分两个小部分：代码编写和配置。

　　代码：三步代码编写

　　代码只需要三步：

　　第一步：域建模：建立sample.model.Message，如下：

public class Message extends Model {
　private Long messageId;
　private String name;

　public String getName() { return name; }
　public void setName(String name) { this.name = name; }
}

　　注意点：

　　·模型类Message必须继承框架的com.jdon.controller.model.Model，或者实现com.jdon.controller.model.ModelIF接口。

　　·该模型类必须有一个能够标识其对象唯一性的主键，如messageId，这个主键相当于数据表的主键。

　　第二步：建立Model组件服务：首先建立模型Message的服务接口sample.service. MessageService：

public interface MessageService {
　public void createMessage(EventModel em);
　public void 更新Message(EventModel em);
　public void 删除Message(EventModel em);
　public Message getMessage(String messageId);
}

　　至于MessageService的具体实现子类可以在现在或者以后建立，可见源码包中的sample.service.MessageServiceImp。

　　第三步：建立Model的表现层边界模型：sample.web.MessageForm，必须继承框架的ModelForm，如下：

public class MessageForm extends ModelForm {
　private String messageId;
　private String name;
　public String getName() { return name; }
　public void setName(String name) { this.name = name; }
}

　　表现层MessageForm内容基本上是从业务层模型Message类中拷贝过来的，主要是为了保持MessageForm和Message的字段一致，我们就可以通过框架内MessageForm和Message的相同字段的复制进行数据传送，将业务层的Message数据传送到表现层MessageForm；或将界面表现层MessageForm传送到Message中。

　　一个模型Message有关CRUD实现的代码工作到此结束，如果有其他模型，完全按照上述三个步骤再做一次，是不是不太费脑筋？有点模板化开发味道？下面谈谈CRUD实现第二组成部分：配置。

　　配置分两个配置文件，这两个配置文件分别是：

　　·将前面三步编写的类建立关系：jdonframework.xml

　　·配置界面流程：struts-config.xml

配置之一：Jdon框架配置文件

　　首先我们将前面三步编写的三个类：模型Message、服务MessageService和界面模型MessageForm建立起联系，也就是告诉Jdon框架这三者是解决一个模型增删改查CRUD功能实现的。

　　由于这个配置文件是告诉Jdon框架的，因此，我们取名为jdonframework.xml，当然你也可以取其他名称，无论取什么名称，都要告诉Jdon框架，在struts-config.xml中配置

＜plug-in className="com.jdon.strutsutil.InitPlugIn"＞
＜set-property property="modelmapping-config" value="jdonframework.xml" /＞
＜/plug-in＞

　　jdonframework.xml配置内容如下：

＜models＞
　＜!-- 配置模型的类是Message，其主键是messageId --＞
　＜model key="messageId" class ="sample.model.Message"＞
　　　＜!-- 下行是配置界面模型MessageForm --＞
　　＜actionForm name="messageForm"/＞
　　＜handler＞
　　　＜!-- 以下配置MessageService --＞
　　　＜service ref="messageService"＞
　　　　＜getMethod name="getMessage" /＞
　　　　＜createMethod name="createMessage" /＞
　　　　＜更新Method name="更新Message" /＞
　　　　＜删除Method name="删除Message" /＞
　　　＜/service＞
　　＜/handler＞
　＜/model＞
＜/models＞
＜services＞
＜!-- 以下配置MessageService --＞
＜pojoService name="messageService" class="sample.service.MessageServiceImp"/＞
＜/services＞

　　以上配置是配置模型Message、模型服务MessageService和界面模型MessageForm三者关系的，下面详细说明三个部分的配置：

　　一、模型Message的配置：

　　这是通过第一行中的class值来指定当前Model是sample.model.Message：

＜model key="messageId" class ="sample.model.Message"＞

　　其中，Message模型的主键是messageId，这个messageId必须是Message类的一个字段；同时是用来唯一标识唯一的Message模型对象，也就是Object ID，或者可以认为是模型Message对应的数据表message的主键。

　　二、界面模型MessageForm配置：

＜actionForm name="messageForm"/＞

　　可能你已经注意到：这里并没有写界面模型完整类：sample.web.MessageForm，而好像是MessageForm类的名称messageForm。
那么配置中messageForm名称是从哪里来的呢？是struts-config.xml中ActionForm定义名称，如下：

＜struts-config＞
＜form-beans＞
＜form-bean name="messageForm" 无效="sample.web.MessageForm" /＞
……
＜/form-beans＞
　…..
＜/struts-config＞

　　可见我们的界面模型完整类sample.web.MessageForm是在struts-config.xml中form-beans中配置，并且命名为messageForm，而这个messageForm就是jdonframework.xml中的messageForm。

　　三、模型服务MessageService配置：

　　在jdonframework.xml中首先申明MessageService完整实现是类sample.service.MessageServiceImp，并且取名为messageService：
＜pojoService name="messageService" class="sample.service.MessageServiceImp"/＞

　　这样，我们就可以详细将我们自己编写的messageService的CRUD方法名告诉Jdon框架了：

＜handler＞
　＜!-- 以下配置MessageService --＞
　＜service ref="messageService"＞
　　＜getMethod name="getMessage" /＞
　　＜createMethod name="createMessage" /＞
　　＜更新Method name="更新Message" /＞
　　＜删除Method name="删除Message" /＞
　＜/service＞
＜/handler＞

　　黑体字部分正是messageService所指的类sample.service.MessageServiceImp所继承的接口sample.service. MessageService四个方法，可见前面代码步骤第二步。

　　配置之二：界面流程配置

　　界面流程主要是配置CRUD界面流程，Jdon框架CRUD流程主要分两个部分：第一是推出供用户新增修改删除的页面；第二是接受用户提交新增修改过的数据，以便递交到业务层保存。

　　这部分配置主要是配置struts-config.xml：

　　第一、配置推出CRUD页面流程：

＜action name="messageForm" path="/messageAction" 无效="com.jdon.strutsutil.ModelViewAction"
scope="request" validate="false"＞
　　＜forward name="create" path="/message.jsp" /＞
　　＜forward name="edit" path="/message.jsp" /＞
＜/action＞

　　其中com.jdon.strutsutil.ModelViewAction是Jdon框架类。只要客户端浏览器调用http://localhost:8080/messageAction.do，通过上述配置将激活forward的name="create"流程，就能得到一个空白表单的页面message.jsp；如果客户端浏览器调用http://localhost:8080/messageAction.do?action=edit&messageId=18，通过上述配置将激活forward name="edit"流程，得到一个填满数据的表单页面，供用户修改。

　　第二、配置：接受用户提交新增修改过的数据，以便递交到业务层保存：

＜action name="messageForm" path="/messageSaveAction" 无效="com.jdon.strutsutil.ModelSaveAction"
scope="request" validate="true" 无效="/message.jsp"＞
　　＜forward name="success" path="/result.jsp" /＞
　　＜forward name="failure" path="/result.jsp" /＞
＜/action＞

　　其实在上一步的message.jsp中已经使用到这一步的配置，在message.jsp的表单action值就是本步配置的path值：/messageSaveAction.do：

＜html:form action="/messageSaveAction.do" method="POST" ＞
　＜html:hidden property="action"/＞
　　MessageId：＜html:text property="messageId"/＞
　　
Name：＜html:text property="name"/＞
　　
＜html:submit property="submit" value="Submit"/＞
＜/html:form＞

　　在上面message.jsp中一定要有＜html:hidden property="action"/＞一行。

　　至此，模型Message的CRUD功能开发完毕。

批量查询实现

　　代码：三步代码编写

　　第一步、表现层编写一个查询Action，继承Jdon框架的com.jdon.strutsutil.ModelListAction，该类名称为sample.web. MessageListAction，完成getPageIterator和findModelByKey两个方法。

　　其中getPageIterator方法内容是业务层MessageService的调用：

MessageService messageService= (MessageService) WebAppUtil.getService("messageService",request);
return messageService.getAllMessages(start, count);

　　所以MessageService接口中必须有getAllMessages这个方法，主要功能是返回PageIterator对象
findModelByKey方法内容也是业务层MessageService的调用：

MessageService messageService= (MessageService) WebAppUtil.getService("messageService", request);
return messageService.getMessage((String)key);

　　MessageService接口中必须有getMessage方法。

　　第二步、业务层实现MessageService接口方法getAllMessages内容，一般是直接调用持久层MessageDao方法。

　　第三步、持久层实现返回PageIterator对象：

public PageIterator getMessages(int start, int count) throws Exception {
　String GET_ALL_ITEMS_ALLCOUNT = "select count(1) from testmessage ";
　String GET_ALL_ITEMS = "select messageId from testmessage ";
　return pageIteratorSolverOfMessage. getPageIterator (GET_ALL_ITEMS_ALLCOUNT, GET_ALL_ITEMS, "",start, count);
}

　　如果有参数，可以如下查询：

public PageIterator getMessages(Long categoryId, int start, int count) {
　String GET_ALL_ITEMS_ALLCOUNT = "select count(1) from message where categoryId = ? ";
　String GET_ALL_ITEMS = "select messageId from message where categoryId = ? ";
　Collection params = new ArrayList(1);
　params.add(categoryId);//参数放在Collection中
　return pageIteratorSolver.getPageIterator(GET_ALL_ITEMS_ALLCOUNT, GET_ALL_ITEMS, params, start, count);
}

　　配置之一：Jdon框架配置文件

　　本步骤主要是需要告诉jdonframework.xml我们的MessageService实现子类是什么，以及调用的MessageDao等组件，jdonframework.xml如下：

＜services＞
　＜pojoService name="messageService" class="sample.service.MessageServiceImp"/＞
　＜component name="messageDAO" class="sample.dao.MessageDAO"/＞
　＜component name="constants" class="sample.Constants"＞
　＜constructor value="java:/TestDS"/＞
＜/component＞
＜/services＞

　　因为MessageServiceImp类中调用了MessageDAO，MessageDAO中又涉及JNDI名称，所以它们之间依赖关系靠Jdon框架的IOC容器实现。MessageServiceImp必须有构造器如下：

public class MessageServiceImp implements MessageService{
　private MessageDAO messageDAO;
　public MessageServiceImp(MessageDAO messageDAO){
　　this.messageDAO = messageDAO;
　}
}

　　配置之二：界面流程配置

　　这一步主要是struts-config.xml配置，和通常struts的ActionForm和Action配置类似：

＜form-beans＞
　　……
＜form-bean name="listForm" 无效="com.jdon.strutsutil.ModelListForm" /＞
＜/form-beans＞

　　其中com.jdon.strutsutil.ModelListForm是框架批量查询特别使用的类。

＜action name="listForm" path="/messageListAction" 无效="sample.web.MessageListAction" scope="request"＞
＜forward name="success" path="/messageList.jsp" /＞
＜/action＞

　　其中sample.web.MessageListAction是我们前面代码编写部分编写的代码。这样，客户端浏览器通过http://localhost:8080/ messageListAction.do就可以实现所有Message批量分页查询显示。

　　注意，messageList.jsp中编码和通常Struts的Jsp编码是一样的，需要使用logic:iterator从ActionForm为listForm的list字段中获取单个的Message对象，然后显示这些单个Message对象,，如下：

＜logic:iterate indexId="i" id="message" name="listForm" property="list" ＞
＜bean:write name="message" property="name" /＞
.........
＜/logic:iterate

　　在messageList.jsp中加入下面标签库可以自动显示多页，缺省一个页面显示30个条目。

＜MultiPages:pager actionFormName="listForm" page="/messageListAction.do"＞

＜MultiPages:prev name="[Prev ]" /＞
＜MultiPages:index displayCount="1" /＞
＜MultiPages:next name="[Next ]" /＞
＜/MultiPages:pager＞

　　模型Message的批量查询功能已经全部完成。

农村宅基地的信息化系统图形应用解决方案
一、系统概述
宅基地狭义的概念：所谓宅基地是指农村合作集体根据生产和生活的需要，分配给农民使用的以修建房屋为目的的地皮。广义上讲还应当包括城市住房建筑用地。从狭义定义上看，宅基地有以下的特点，首先是发生地在农村，具有很强的范围性、身份依附性；其次是分配的仅是其使用权，主要是为了保障每户农民的居住需求，具有社会保障功能；第三是其应当适合建筑的一般要求。本文所谓的房屋是指以宅基地以上的以生产和生活为目的的建筑物。
农村宅基地使用现状：1. 宅基地闲置情况2. 宅基地的扩张与耕地的矛盾3. 城市人到农村购买购置房产等等。
为了防止人为原因造成宅基地批放失误和从源头减少矛盾,建立宅基地信息管理系统对宅基地信息进行数据化信息化智能化管理。 将每户宅基地的家庭人员情况、位置、批准时间、户住宅的四边及其相邻的户号或街号等信息存入信息库，为信息查询、数据分析、信息变更等提供了依据。将每户宅基地的每一个界址点在实地作了标记，在地图数据库中对应每个标记做了坐标，有效的控制与管理宅基地，大大提高土地资源的利用率。
二、系统特征
农村宅基地的信息化图形管理系统，是一种较以前的MIS（传统信息管理系统）、档案系统、数据系统等管理系统更为先进的信息化管理系统，以地理、坐标、图形、宅基地各种属性数据、空间信息、历史数据为存储信息的管理系统，便于各种层次的管理者、领导及相关人士对农村宅基地信息进行信息查询、数据分析、信息变更、档案级数据存储、数据挖掘等信息操作行为。农村宅基地系统有以下特征：
1. 具有采集、管理、分析和输出多种宅基地空间信息的能力，具有空间性、时间性和动态性。
2. 是一种分布式宅基地信息系统，具有逻辑上统一、物理上分布的特点。分布特征表现为：各级go-vern-ment所管辖的行政宅基地空间范围与权限授予，以及所管辖范围内的不同行业、部门单位对系统的使用权限，个人家庭的宅基地空间分布详细信息。
3. 规范宅基地编码，使之应用于可以以图形系统为核心的数字化成图。

三、基于Visual Graph的宅基地图形应用需求
3.1．易开发易集成GIS应用功能：
Visual Graph图形系统适合开发地理信息系统，尤其对于宅基地类型的管理，完善的地图编辑功能、多图层、图形分级显示，有极其丰富的填充图案和线条形状。可以很好地转换现有的其他GIS平台的图形格式，用户无须关心图形的一切表现，因为Visual Graph为GIS的图形表现提交了所有的功能。省时省力省成本，但质量绝不省约的开发模式的优势尤其明显。
宅基地信息数据编辑负责建立宅基地空间数据的拓扑关系，实现宅基地空间数据和宅基地属性数据的关联，完成宅基地数据的增加、删除和修改; 宅基地数据管理模块负责宅基地数据库的定义、建立、访问和维护; 宅基地数据操作模块负责对空间数据进行放大、缩小和漫游操作，对宅基地空间数据及宅基地属性数据进行双向查询与分析。
3.2．专家级的产品品质：宅基地信息管理的高档次
Visual Graph 在可靠性、兼容性、易用性、扩展性、完备性、容错性等多方面均达到了产品级的较高的水平。Visual Graph经过近十年的深入研究与百多家大型项目工业上的应用，有预见性地开发了大量具有潜在GIS与图形控制应用的功能，长期与图形系统应用用户互相合作，大量吸取用户GIS图形应用经验，这一切的成熟性造就任何基于Visual Graph的图形系统都具有工业级的稳定性与专家级的品质。
3.3．图形数据无缝链接：
1.响应众多的图形操作事件
任意给图形添加属性成函数，任意自定义图形。每个图形都是对象，拥有众多的属性和函数，可以方便地编辑和操纵图形与数据。
2.任意方便简单地自定义多类型存储宅基地信息的属性数据（整数、小数、逻辑、字符串）
当程序员想给图形添加一些特定的宅基地数据时，可以给这个图形随便增加自定义属性，对自定义属性的读写、存储等操作和对固有属性没有区别。 自定义任何属性，类似流行编程语言中“属性”的概念。把一些流行编程语言（ Delphi 、 C# 等）的“属性”概念引入到 Visual Graph 中，从而使得系统变成了一种似乎无所不能的面向对象编程语言。你只需要简单地修改一个属性的值，就可以驱动图形做任何复杂的变化与宅基地数据信息的改变。
3.任意方便简单地自定义函数（私有、公有函数）
既然有脚本，就离不开自定义函数，函数按照作用域的不同，分为私有函数、公有函数、引出函数三种，如果一个函数只想被内部的其他图形访问，可以使用私有函数，如果允许外部图形访问，可以使用公有函数，如果这是一个触发事件，则可以使用引出函数。这些非常符合一般面向对象编程语言的习惯。函数与过程的区别仅在于是否在 return 后面有返回值。函数参数没有显式的类型，会根据调用者的参数决定。这样设计的结果，使得脚本在形式上更加简洁。

3.4．开发出来的图形系统天生的易用性
图形开发技术完善，拥有比VISIO、WORD、EXCEL等其它图形软件让用户更容易使用的能力与特性，即使不会使用VISIO、WORD、EXCEL的人员，在十分钟之内就可以学会用之开发出漂亮、标准、规范、正确的图形出来。
其基于Visual Graph图形应用系统就具有的以下特性：多页面、多图层、表格图形混排、透明度、自由旋转、动画效果、自定义线型、网纹、箭头、自定义任意多个文字标注、自定义提示窗口、自定义图元连接点、自定义光标、图形保护、控制点，支持图形的逻辑分组，允许图元嵌套构建更复杂的图元，可以给图形添加属性或者函数……。
3.5．快速高效的web图形应用
图形和图库是统一的XML格式，便于传输、存储和维护，支持WEB开发。Visual Graph ActiveX插件尺寸小（cab文件300k），功能全。对于各个领域在WEB上的应用都能很好地发挥。现在系统的WEB化已经成为大部分人的认可，而使用了Visual Graph ActiveX的系统，将可以平缓无缝地移植到WEB来。
四、基于Visual Graph的图形应用设计方案
4.1宅基地信息系统层次划分
宅基地信息系统有三大块组成： 前台图形查询操作系统、图形编辑系统、地理数据存储系统
前台图形查询操作系统：主要用来给不同层次或领域的用户对宅基地信息进行查询与分析。
图形编辑系统：由于宅基地信息的随时间空间的变化，那么就要对此户的宅基地信息进行属性修改、增加与删除。并保持数据与图形的一致性。
地理数据存储系统：用于存储宅基地信息与图形信息的数据库系统，不用说，此系统就是核心。


4.2宅基地数据信息编码规范与存储设计
数据库表设计：
数据库表可以分成两大块：1.图形信息与图形关联信息表，由于Visual Graph天生的XML与VG脚本文本化，所以图形和脚本非常容易存储在数据库表里面，并且可以在互联网网上以XML格式任意流向；2. 宅基地信息数据表，此表主要用来存储所有一切关于宅基地信息的数据，所以此表中的数据是以国家标准和go-vern-ment标准规范化了的数据。
数据表的图形与宅基地信息数据表的对应是以图形文件ID的图元ID对应宅基地ID。
宅基地信息数据编码：
基于Visual Graph图形平台建立宅基地图形信息系统，而宅基地图形数据库信息分类编码是宅基地图形信息系统设计过程中一个关键的问题。宅基地图形数据库建库是系统建设过程中工作量较大的工作，如果宅基地图形数据库信息分类编码体系不合理，甚至不进行分类编码，将增加系统建库工作量，影响宅基地图形信息系统的使用和信息共享，甚至将缩短宅基地图形数据库的生命周期。因此，建立一个完善的宅基地图形信息编码体系，对宅基地图形信息系统的建设至关重要。但是，目前由于国内相关部门制订的国家基础地理信息要素分类编码标准中还没有细化到关于宅基地图形要素分类的编码。因此为了便于系统开发，建议提出一种基于宅基地图形的特定数据组织结构的信息分类编码及其应用。

4.3图形文件显示结构安排
由于一般地理信息系统数据量非常大，所以现在所有主流GIS图形应用技术都是用层次显示的结构方式来显示图形与数据：现在基于县为一层，镇为一层，村为一层，这样以三层的形式就可以表现整个县级的图形了，在宅基地信息查询时，也能全局搜索，从而能知道此住宅是属于那一个图文件里面的那一个图形。于是就可以实现宅基地信息系统的清晰层次结果，对文件进行种种授权控制访问就相对简单了，系统也会变得更加灵活了。


4.4地理图形的输入与输出
由于画地理图形是整个系统最繁杂的一个部分，一般地理应用系统是用买的方式，向地理信息商购买所在的县的所有地理信息，然后再分层转化为Visual graph的图形格式，最后就可以对图形进行编辑与宅基地信息关联设置。以后就可以对此图形进行编辑修改了。把图形文件放到服务器上授权共享，那么就可以让用户对地理图形进行查询与编辑了。



4.5图形属性与宅基地数据联系
每一条宅基地数据都设有一个ID号，那么它将会图形文件ID里面的图形元素ID进行对应，那么就会有以下的联系：

4.6宅基地管理系统的数据初始化
首先初始化地理图形信息，把图形文件显示的图形与现实中的宅基地地理位置要一致，于是一定的修改与编辑不可避免。
首选把此县里面所有的住宅用户的所有相关信息以编码的形式输入数据库
最后就是关联一下图形与住宅用户的信息，那么就此系统就形成，并且可以交付使用了。
最后设计出来的系统，就是不懂地理不懂画图的人，也可以对此系统进行信息操作，因为系统面对用户的将是一个个关于宅基的信息元，一个个标准化的图形操作，一切对系统的操作变得规范而有序。
4.7系统的WEB应用。
Visual Graph目前广泛应用于图形GIS系统中，例如绘制地图、电网GIS拓扑分析等。在web时代，由于Visual Graph具有体积小、功能强的优点，很容易作为插件在IE浏览器中工作。




五、基于Visual Graph图形引擎的图形开发优势
一般公司而言，所只关心的就是业务逻辑方面，而人机界面、图形交互这一系统基础则没有多大的研发能力，因为开发一个图形交互的应用系统，所要考虑的方方面面不亚于开发一个象VISIO这样的图形处理软件，所以大部分公司的项目与产品的开发就是在图形处理这一步骤中被卡住了。由于图形处理这一块开发得不完整，从而影响了业务逻辑的实现，加大了业务逻辑的复杂性，从而影响了开发图形系统的速度、进度、效率、质量；从而影响了图形应用项目或产品的易用性、扩展性、适用性、简单性、健壮性、安全性、兼容性以及系统的品质；从而影响了公司的效益，公司的信誉、公司的产品的形成、公司业务的拓展、公司的人力物力的严重无为的浪费。
市场一致认为，基于Visual Graph开发图形系统拥有以下优势：
1. 开发出的产品质量高，技术先进，很容易达到产品先进技术水平
2. C/S、B/S完美过渡，系统可以在互联网上快速稳定运行
3. 可以短时间内开发出一个专家级、成熟、满足客户需要、运行稳定的图形应用产品
4. Visual Graph拥有许多图形应用系统的开发经验，可以解决开发过程中所有出现的问题，如果需要，可以协助开发。
5. Visual Graph的细心专业、24小时全天技术服务、图形应用同行的解决方案确保图形应用产品的品质与开发的进度。
6. 项目变成产品，可以从项目经验中迅速形成拥有公司自主产权的图形产品，拓展公司业务，提高公司效益。

太专业
帮顶

太专业
帮顶

我虽然不懂.但是我希望你能给我点MP.因为我就快可以用猫爪

帮顶的还有没MP呀

回复了
说我发的是垃圾贴
有没有搞错？？？？？

路过 帮顶

帮顶，这个还真专业

路过,
顶一下,
顺便分点mp,
谢谢lz!!!

居然啥也没看懂```

sap＆oracle是目前世界上公认的两大管理软件品牌，他们占据着绝大多数的市场份额，至于其他的几个也在局部地区做得不错，只是严谨性＆系统性不如前两者，适合小公司使用，对于sap＆oracle的比较，您可以参考以下文档：
1:软件产品的成熟度

§ SAP：经过近30年与全球大企业用户的合作，SAP系统积累了大量先进企业的业务管理流

程。对于用户来说，只需根据在系统中挑选适当的业务流程，在软件中进行配置。而对软件的二次开发工作量极少，这就保证了用户能够把主要的精力都花在企业业务流程的优化上，真正起到上一套系统，管理提高一个层次的作用。

§ Oracle: 由于缺乏足够的业务流程模板和软件功能的支持，在实施中Oracle软件经常被发现无法满足企业管理上的要求。比如在大型制药企业中必须的批次管理、质量管理、设备维护管理等，而Oracle软件根本没有此类模块。虽然Oracle公司一再的夸大告诉客户其软件的二次开发技术十分灵活，但是这实际上也就是在告诉用户这套软件功能不够，用户得自己去编程序。

§ SAP：秉承德国企业严谨的文化，所有发布的产品都是经过严格的测试和质量认证，只有在软件产品真正完备后才向用户推出。

§ Oracle公司是一个非常注重市场效应的企业，经常是一有概念就马上宣称产品完成，然后快速推向市场。但是，软件产品得漏洞和缺陷给其用户得实施和使用造成了巨大的痛苦。2002年1到3月，Oracle发给新产品用户的修补程序包竟然高达5000个以上，这对用户来说无疑是一场恶梦。

§ SAP：作为ERP系统的重要组成部分，SAP花了2年的时间进行汉化和按照中国go-vern-ment的人事管理要求进行本地化，使得SAP的中国用户不仅能够使用国际化的先进软件，同时也满足本地化的要求。

§ Oracle：对ERP软件产品本地化重视不足，至今在中国地区，Oracle的用户还没有一家能够使用Oracle软件的人力资源管理模块。

不同的产品质量和市场策略，造就了不同的用户群体

SAP在中国

公司经营理念的不同，最终一定会反映在其用户群体的实施效果上。以中国为例，SAP的用户群体中，大型企业实施成功的比比皆是，这些企业纷纷把自己的成功经验向社会传播，报章媒体上宣传实施SAP实施成功的文章时时可见，比如：


2001到2002年中，又有中国最大的矿业集团－兖矿集团，列入全球财富500强的－中国石油化工集团，国内四大通讯设备厂商之一－大唐电信集团，中国最具活力的报业集团－广州日报集团等大型、浦东发展银行超大型企业纷纷加入SAP的用户群体。

Oracle在中国：

与SAP的广泛成功形成鲜明对比的是，Oracle依靠低价格来得到的客户，实施效果却良莠不齐，鲜见有在媒体上宣布自己实施ERP成功的；特别是在大型企业集团的实施上，鲜见其有成功客户。特别是在一些大型项目上，其急功近利的市场策略造成的恶果已经开始显现。

§ 中国移动通信：在广东、江苏、浙江的试点实施Oracle系统，软件的先天不足和实施力量的经验缺乏造成实施瘫痪。2001年7月，中国移动痛下决心，对尚未实施Oracle的其他13个省的ERP项目重新进行招标，而邀标书就发给了SAP 。而作为中国移动的母公司，中国电信，吸取前者的教训，谨慎的进行评估和实施。在北京电信公司和上海电信公司已经开始实施SAP。

§ 上海宝钢：产品无法适应大型企业复杂的管理需求，实施半途而废，现在宝钢已经完全放弃了系统的使用。

§ 中国民航：实施力量薄弱，在试点实施效果不理想的情况下，中国民航进退维谷，既没有信心向全国推广，也没办法放弃。

§ 实达电脑：Oracle在中国最大的实施合作伙伴－汉普公司，其实施能力让实达公司的领导层忍无可忍，只好中途将汉普的咨询队伍“请”出了实达公司。Oracle公司只好换上其他合作伙伴，但实施何时能够完成，还无法预料。

§ 江苏沙钢集团：从1997年开始实施Oracle ERP，经历了漫长的实施过程和庞大的二次开发工作后，终于在2002年5月放弃了Oracle软件，转向SAP。

以上这些案例足以说明，Oracle的两大致命弱点：软件功能不足、实施力量薄弱决定了，其方案在大型集团化企业的项目上的成功十分困难。这些先天的障碍，给这些大型集团化企业的信息化甚至是企业经营造成了巨大的隐痛。

2、 技术的先进性

Oracle 应用系统11i 版本是真正完全基于互联网INTERNET架构，并且采用开放的JAVA语言和技术标准进行编写的应用软件，这种技术的开放性，使Oracle 应用系统11i版本有越来越强的生命力（开放的标准意味着应用系统软件不受硬件平台, 不受企业规模大小, 不受地域限制等因数的影响)，而SAP软件的主体部分还是完全用其私有的ABAP语言编写的，学习和使用都很困难且与INTERNET或网络应用WEB技术不兼容（JAVA目前已经成为全球INTERNET应用系统的应用开发标准，而懂ABAP语言的开发人员非常少），虽然SAP也在试图转向JAVA标准，但由于其目前的系统过于复杂和庞大，完全的转型几乎不可能。非INTERNET结构上的应用系统, 基本是基于客户/服务器(C/S)的结构,这在现在的INTERNET时代,是已经过时或被淘汰的技术,它将限制应用系统的规模和并发用户数,也不可能用于全球一体化的管理系统 – 即跨国或跨地区的大型企业将不可能应用一个数据库的管理系统, 这将给这些选用该C/S 系统的企业带来巨大的系统投资费用和系统维护成本, 也使企业不可能在今后发展时,继续使用已投入的信息系统, 即在原系统上增加新功能/系统的逐步实现企业信息化的设想成为不可能。

虽然从表面上看，最终用户似乎感觉不到软件技术架构带来的变化，但事实上，是否选择符合发展潮流的技术方向会极大地影响到软件厂商及其应用客户的生命力。历史上，由于没能选择符合潮流的技术而迅速衰落的大软件厂商比比皆是（曾经在ERP领域领导潮流的SSA，由于不能将系统及时转向开放的UNIX平台，而迅速衰落）而这同时也给选择这些厂商产品的客户带来了极大的风险。

ORACLE应用系统充分采用了数据库上的先进技术，将有些系统功能放到数据库中去实现，而不是通过编程的方式，因而大大简化了程序，提高了效率。而SAP系统为支持多种数据库，不可能采用数据库技术去实现数据库端的功能，只是将数据库用来储存数据，其原因有两方面，一是SAP公司不是数据库技术公司, 不专注于数据库技术，二是SAP也不愿意将自己的产品捆绑在一种数据库上，但这种做法牺牲了客户的利益。

ORACLE系统具有强大的查询功能，在其输入数据的界面中，输入的任何数据都可做为其查询条件。SAP则需要专门定义查询界面。

ORACLE 电子商务套件已经脱离了传统的ERP软件模式，提供了集成的商业智能、个性化管理界面、工作流和告警等全新的功能。传统的ERP软件，用户需要进入层层菜单，运行查询或报表，才能得到业务数据。而使用ORACLE，用户可以在个性化的企业门户网页中，自由定义所需的智能报表，就能迅速了解企业、相关业务的执行情况。系统还能够对非正常业务自动告警。ORACLE 系统以人为本，帮助企业的管理人员充分利用ERP的业务数据，更高效地管理企业。

3、 创新性、生命力、在新兴应用领域的发展

由于ORACLE相对于 SAP 先天的技术优越性，使ORACLE能够根据各行业的发展变化趋势，迅速将产品拓展到各种新的应用领域。例如，ORACLE在客户关系管理、电子商务、产品协同开发等各行业的新兴领域都要领先于SAP，显示出ORACLE卓越的创新能力和越来越强的生命力。而SAP由于本身体系的复杂性和技术的封闭性，使得其在各种新的应用产品领域进展缓慢，例如，SAP虽然已经拥有庞大的制造业客户群，但在客户关系管理领域一直碌碌无为，在B2B电子商务方面也不得不依靠与Commerce One的合作，直到2001年才解除与Commerce One 的合作，推出自己的产品。

4、 业务数据的共享和分析

随着企业应用管理领域的不断扩展，企业应用系统涉及的范围也越来越广泛，从传统的制造、财务、人力资源系统管理，开始延展到客户关系管理、供应链管理、电子商务等方向，在这种情况下，系统之间数据的一致性和数据交换，就变得非常重要。ORACLE 11i 整个系统基于一个统一的数据库，并且共享统一的数据模型。企业内所有的用户都可以根据自己的角色和权限对系统中的数据进行不同维度的分析。而SAP的ERP、供应链、客户关系管理、数据挖掘等应用系统分别构建在不同的数据库上，不同系统间的数据模型也不相同，这使得各系统之间的数据共享变得非常困难或者不可能。

5、 软件功能的比较

SAP体现了德国人的管理风格：求严求全；ORACLE体现了美国人的管理风格：求实求用。

SAP
SAP 功能复杂、全面，特别在传统的ERP功能方面，系统功能设计比较细致。SAP通过复杂的参数表、层层定义来实现各中功能。系统可以通过6000 个“开关”设置，调整软件的业务流程。SAP参数设置是非常复杂的，例如，对采购定单下达过程的管理，SAP需要预先定义：先定义定单特征码，再定义相应的特征（如金额大于100圆）、分类、下达组（Release group）、下达编码（Release codes）、下达标志（Release indicator）、下达策略（Release strategy），工作流标志等，再通过一系列规则表值的设置，才能实现采购定单批准下达的过程。如果需要修改下达过程，则必须从定单特征码开始修改。

SAP的参数设置实际上包括了软件的底层数据结构，功能较强，但实施非常复杂，不够灵活。如果企业的业务需要调整，就会涉及非常多的底层数据设置，参数和规则的调整，甚至可能影响已有业务数据。

SAP在CRM（客户关系管理）和E-Business（电子商务）方面已远落后于ORACLE。

ORACLE
ORACLE 软件的业务流程控制结构非常灵活，并充分利用工作流的功能来控制软件的业务流程。因此，可以灵活地调整软件的业务流程。例如，同样对采购定单的下达过程，ORACLE 利用采购定单的数据（不须设置特征参数），通过工作流引擎，自动检查采购定单的数据，如金额、采购员、供应商等，根据条件判断，实现不同的采购定单批准下达的过程。如果需要更改业务流程，无须更改特征参数，只需更改判断规则或控制规则。

ORACLE 的控制参数设置不须修改数据结构，而是通过采用不同的控制参数来调整程序的逻辑。这是因为ORACLE 采用公共的数据模型，程序中充分利用现有的业务数据，通过灵活的规则设置来实现灵活的业务流程。

ORACLE 在新的业务功能占据优势。如混流生产、CRM、电子商务协作等，都是根据最新的业务模式和知名客户的实际业务流程开发的。

结论

由于企业的多样性和复杂性，任何ERP软件都不可能覆盖企业的方方面面。ORACLE较能适应企业的业务的个性化，便于调整；而SAP较适应稳定、标准的业务流程，难以改变。这也是SAP强调SAP代表了先进业务流程，要求企业适应软件的原因。

6. 软件的开放性和集成性

SAP
SAP的软件各模块在搭建上采用的是传统应用软件的模式，即在程序中用包含头函数以及子程序等模式。这种模式在与第三方软件交换数据时，只能通过编写接口程序来实现。SAP软件的应用层是使用ABAP语言编写的程序，ABAP是比较复杂和只有SAP软件使用的语言，比较难掌握，又由于其只能在SAP的软件中才能发挥用途，掌握的人也很少. IT专业人员学习它的积极性也不高. SAP系统在与外界交换数据时, 其接口程序也要求用ABAP语言来编写，具体是用ABAP语言中的函数来向系统中导入数据，其对数据的格式要求也很高，要求的数据必须是带分格符的文本文件。SAP的这些做法导致其软件系统在同第三方软件集成上远远落后于ORACLE，同时这些做法也阻碍了其自生软件的进一步发展，这也是SAP的ERP与CRM不能完全集成的原因之一。

ORACLE
ORACLE公司凭借其在数据库方面全球领先的优势，其应用软件在模块的体系搭建上采用了一种先进的模式，各模块之间以及与外界交换数据都必须通过接口表来完成，具体的做法是数据要进入各模块时，都必须先到各模块自己的接口表中（每个模块都有自己的接口表），然后再通过并发等方式导入该模块中，这种模式很容易将第三方的软件融入ORACLE的系统中，用户在使用时很方便，感觉象是一套软件，因为在交换数据时第三方的软件与ORACLE的产品各模块间交换数据的模式是一致的，同时用户可以以自己熟悉的数据库语言（VB，PL/SQL等）来编写应用程序与ORACLE系统集成。

ORACLE凭借其软件系统在体系上的优势，将其ERP、CRM，SCM，EB等系统完全集成为一体，形成今天的电子商务套件。

结论

任何ERP软件都不可能覆盖企业的多样性和复杂性的所有方面，对于企业的特殊要求用户自己可进行必要的二次开发，并可以同其他应用软件方便地集成，这就要求供应商提供的软件具有很强的开放性。ORACLE 开放、灵活的体系结构更利于企业信息系统未来的扩展。

7. 软件的实施复杂性及投资回报

SAP项目实施过程十分昂贵和复杂。 而且，由于其软件的复杂性和封闭式集成，一旦实施后很难改变。另外，SAP在项目实施过程中，经常会期望客户改变商业运做模式以适应其软件， 但有时候，一味迁就软件流程的做法很可能会给客户带来负面结果。一些超大型企业可以投入巨资进行软件的客户化，但是对于中等规模的企业，复杂的项目实施，往往会将客户拖入无休止的泥潭。国内一汽大众的SAP ERP的累计实施投资已经过亿圆，但实施效果其实并不理想。之后一汽又选用了与SAP的ERP “配套” 的CRM供应商SIEBEL软件, 其CRM系统实施了几年, 至今没有上线。而Oracle 的应用产品具有很强的灵活性，许多业务的流程可以通过工作流技术很方便地进行改变，同时Oracle 系统本身的开放性也使Oracle 系统与其它系统的集成变得相对简单。

实施问题：

1、我的企业管理流程与你们软件有差异，怎么办？

2、听说ERP实施难度很大，成功率低，你们怎么看？

SAP
SAP对所有行业都有完备的解决方案，我们的专家将协助你选择最佳模式；如果你现有的业务流程与SAP系统有差异，建议调整你的业务流程。

首先，这个说法并不十分确切，SAP在著名的跨国公司的成功就说明了问题；其次，很关键的问题在于客户，尤其是许多中国客户对企业信息化的理解不足，基础管理水平较低；

SAP系统对顾问和用户的要求都很高，特别是在SAP系统中，很多功能需要先在后台设置参数，再通过编写专门的ABAP语言程序来实现。这种情况下往往要求顾问和用户既懂应用，又具有一定开发方面的知识，因为ABAP开发人员一般是不懂后台应用系统设置的，而应用实施顾问往往又不知道这种与开发相关的系统设置，这种情况就是在SAP自己的实施队伍中都会碰到。

SAP过于复杂，很多不适合中国企业的功能混在一起，有6-7千个参数需进行设置，用户非常难以掌握。投入大量资金也很难培养出来合适的技术人员。然而, 即使培养了一些技术人员, 一旦跳槽，则系统就会面临瘫痪。

ORACLE
首先，系统灵活和开放, 有几乎所有流程/模块的系统界面, 基于丰富的行业经验基础上开发的优秀业务模型和标准流程和功能可满足客户的需求, 也可供客户借鉴；其次，如果客户不满意已有的流程和功能，IT 行业使用最广泛的ORACLE开发工具将可方便地使用户按其要求进行客户化开发来满足企业的需求。

首先，这是事实；其次，实施是软件商和客户共同的事业，必须选择适当的策略，给予充分的支持才有可能成功。

ORACLE系统提供了清晰的业务流程，可以帮助企业在实施的同时理顺业务流程。ORACLE 的业务流程可以根据企业的实际情况灵活调整，更适应企业的个性化管理。

ORACLE数据结构清晰、严谨，开发工具使用的是世界 IT 行业最普遍使用的语言, 如: JAVA 这唯一真正INTERNET计算机语言，易于开发, 且开发的系统才是真正的INTERNET上的应用系统。

结论

ORACEL 更适用于业务复杂、个性化管理的企业。ORACLE软件实施的难度和复杂性，实施成本，风险远低于SAP。由于其系统的特性，SAP的实施成本、实施周期远大于ORACLE。


找得很辛苦。。。MP。。。MP。。。

不清楚，只能帮顶

帮顶@！！！
只为MP来！

看了半天不知道你要什么数据，。。。就帮你顶一下吧

帮你顶吧