文章列表
 
您正在查看 "数据库 编程" 分类下的文章

2010年03月20日 22:33

十年学会程序设计

Peter Norvig (Copyright 2001) 原文网址

为何大家如此匆忙?

走进任何一家书店,你会看到书架上一排不见尽头的放着如 <7天自学Java语言> 以及几天或者几小时学会Windows, 因特网或者Visual Basic 这类书。我在Amazon 网上书店用一下的方式进行高级搜索:

出版年份: 1992以后 书名包括:“天” 和 “学习” 或 “自学”

得到了268条搜索结果,其中前78条都是计算机书(第79条是 30天学会孟加拉语)。 我用 “小时” 代替“天” 作为关键字,得到了神奇般类似的结果:这次有253本书,前77本是计算机书, 第78本是 24小时自学语法和写作风格。排名前200的书中有96%是计算机书。

由此可见,人们要不就是急着想学会计算机,要不就是计算机相比于其他事情太容易学会了。比如说把,没有书是写在几天弹奏贝多芬或几天学会量子物理,甚至也没有几天学会帮小狗打扮这样的书。

让我们分析一下 三天学会Pascal语言 [英文网页] 这样的标题表达了什么意思:

  • 学会:

在 三天内,你没有时间去写几个有意义的程序,或者从成功和失败中学到东西。你也没时间跟有经验的程序员一起工作,所以也无法了解在真正编程是什么样子。简短 的说,就学会而言,时间显然不够。所以这些书只是浮于表面的熟悉,而不是深刻的理解。如同Alexander Pope 所说,一知半解是危险的。

  • Pascal 语言:

三 天内你可能学会Pasacl语言的语法(如果你已经掌握一个类似的编程语言),但你无法学会如何合理运用这些语法。简言之,如果你是个Basic 程序员,你可以用Pascal 语言写出类似Basic 风格的程序,但你学不到Pascal语言的优点(还有缺点)到底在哪。重点是什么呢? Alan Perlis 曾说: “如果编程语言不能影响你的编程思维,那就不值得去学.” 另一个可能是,你必须学会一点点Pascal语言(或是像VB语言、Javascript等),因为你需要跟现成的工具组合完成特定的工作。不过这个时候,你实际上学的不是怎么写程序,而是要学着如何完成工作。

  • 三天

不幸的是三天根本不够;下面的章节会告诉你为什么

十年学会程序设计

研究者 Hayes, Bloom 的研究表明,在几乎所有的各种领域,大约要十年才能培养出专业技能。这些领域包括下西洋棋、音乐作曲、绘画、钢琴、游泳、网球,及神经心理学和数学拓扑学。似乎没有真正的捷径--即便是莫扎特在四岁就展露出音乐天才,在他写出世界级的音乐之前仍然用了超过十三年的时间。

再看另一种类型的领域。披头士乐团似乎是在1964年的Ed Sullivan 剧场表演突然地火起来并成为第一乐队的。但其实他们从 1957 年开始,就在利物浦、汉堡等地的小型俱乐部表演。虽然他们很早就显现强大的吸引力,但他们决定性的成功作品 Sgt Pepper 也到1967年才发行。Samuel Johnson 则认为或许还不止十年才行,他说:任何领域的卓越成就都必须用一生的努力才能取得; 稍微低一点的代价都是换不到的。Chaucer 则感叹道: “生命如此短促,学习技艺却要这么地长”

以下是我在编程上成功的秘诀:

  • 对编程产生感兴趣并因为乐趣而写程序。确信你自始至终都能乐在其中,这样你才愿意将十年光阴投入编程事业.
  • 与其他程序员交流;阅读别人的代码。这比任何书任何培训都重要。
  • 不断地编写。 最好的学习方法是在实践中学习 。从技术角度说,”在特定领域的个人最高效率并不因为经验够多就会自动获得;但若有意识的通过努力去提升经验,个人效率会变高”(第336页)而 “高效的学习一般需要明确的任务和因人而异的适当难度,以及及时的反馈和重复或者修正错误的机会”(20~21页)Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life 实践中认知:心智、数学与日常文化) 是这个观点的一本有趣参考书籍。
  • 如 果你愿意,你可以去读四年大学(或再读研究生)。这可以让你满足一些工作的学历要求,同时也可让你对这个领域有更深的认识。但如你不喜欢上学,你也能(得 有牺牲)通过工作获得类似的经验。无论如何,只读书是不够的。《New Hacker’s Dictionary》的作者Eric Raymond 曾经说过: “计算机的教育无法让人成为编程的专家,正如研究画笔与颜料不能让人成为专业画家一样.” 一个在我所有招聘过的人中属于最优秀之一的程序员只有高中毕业,但他写出很多很棒 程序,他甚至有自己的新闻组。他获得的股票期权使得他可以拥有自己的午夜酒吧.
  • 跟其他程序员一起完成项目。在一些项目中成为最好的程序员;在一些中则充当最差的一个。当你是最佳的,你要测试自己领导项目的能力,并以你的能力鼓励他人。当你是最差的,要看看高手做些什么,他们不喜欢做什么 (因为他们会叫你去帮他们做).
  • 接手别的程序员完成项目。全心投入并理解别人的程序。当原作者不在的时候,看看在理解与修改时有什么要注意的。想想如何设计你的程序使得后来维护的人容易上手。
  • 至 少学会六门编程语言。一种要支持类/对象(class abstractions)的语言, 如Java或C++; 一种函数式(functional abstraction)语言, 如 LISP 或 ML; 一种支持语法抽象(syntactic abstraction) 的语言 如 LISP; 一种声明式语言, 如Prolog或 C++模版; 一种支持协同式(coroutines)编程, 如 Icon 或 Scheme; 还有一种支持并行(parallelism)的语言, 如 Sisal.
  • 记住在 “计算机科学” 中包括”计算机” 这个词。要知道你的计算机执行一条指令需要多久,到内存中取一个字需要多久(缓存是否击中), 到磁盘读取连续的字需要多久,而磁盘的定位又需要多久. (解答见文末)
  • 进行语言标准化的工作。可以像是由ANSI C++ 委员会,或由你自己的团队,来决定你们的编码风格,譬如说缩排是2或4个空格。不管怎样,你都能学到别人到底喜欢什么,对语言的感受有多深,甚至能了解到一点他们为什么有这样的感觉。
  • 并具备良好的判断力,也别老纠缠在语言标准化上.

谈 了上面所有的想法后,我不禁要问究竟能从书上学到多少。在第一个孩子出生前,我读完了所有的 “怎样…” 的书,仍觉得自己是个一无所知的(照顾孩子的)菜鸟。30个月后,第二个孩子出世,我要重回这些书好好复习么? 不! 取而代之的是,我开始相信自己的个人经验。这些难得的经验,比专家写的几千页手册还要有用,而且让我重新找到了自信.

Fred Brooks (译注: <人月神话>作者) 在他的文章 没有银弹 中指出,发掘卓越软体设计者的三部曲:

1.尽早尽可能地以系统化的方式发掘最佳设计人员。
2.给有潜力者指派生涯规划师,并谨慎地规划他们的职业生涯。
3.提供机会给正在成长的程序员,让他们能相互影响,彼此激励。

这里假定了某些人已具备成为卓越设计师的必要潜能;工作只是诱导他们前进。Alan Perlis 说得更简洁了,你可以教任何人学雕塑,但对米开朗基罗而言,要教他的
反倒是有哪些事不要做, 卓越的程序员也一样。

所以,尽管买那些 Java 书吧!你或许能从中找到点有用的,但是在24小时,几天或者几个月中,这些都不会改变你的人生,你也不能掌握一个真正的程序员应该具备的真正的综合的技能。


参考文献:

Bloom, Benjamin (ed.) Developing Talent in Young People, Ballantine, 1985.

Brooks, Fred, No Silver Bullets, IEEE Computer, vol. 20, no. 4, 1987, p. 10-19.

Hayes, John R., Complete Problem Solver Lawrence Erlbaum, 1989.

Lave, Jean, Cognition in Practice: Mind, Mathematics, and Culture in Everyday Life, Cambridge University Press, 1988.

 
2009年07月18日 22:04

摘抄自《OOD 启示录》--Arthur J.Riel
文章来源:http://www.21tx.com/dev/2004/10/09/11399.html

(1)所有数据都应该隐藏在所在的类的内部。p13

(2)类的使用者必须依赖类的共有接口,但类不能依赖它的使用者。p15

(3)尽量减少类的协议中的消息。p16

(4)实现所有类都理解的最基本公有接口[例如,拷贝操作(深拷贝和浅拷贝)、相等性判断、正确输出内容、从ASCII描述解析等等]。 p16

(5)不要把实现细节(例如放置共用代码的私有函数)放到类的公有接口中。p17
如果类的两个方法有一段公共代码,那么就可以创建一个防止这些公共代码的私有函数。

(6)不要以用户无法使用或不感兴趣的东西扰乱类的公有接口。p17

(7)类之间应该零耦合,或者只有导出耦合关系。也即,一个类要么同另一个类毫无关系,要么只使用另一个类的公有接口中的操作。 p18

(8)类应该只表示一个关键抽象。p19
包中的所有类对于同一类性质的变化应该是共同封闭的。一个变化若对一个包影响,则将对包中的所有类产生影响,而对其他的包不造成任何影响 .

(9)把相关的数据和行为集中放置。p19
设计者应当留意那些通过get之类操作从别的对象中获取数据的对象。这种类型的行为暗示着这条经验原则被违反了。

(10)把不相关的信息放在另一个类中(也即:互不沟通的行为)。p19
朝着稳定的方向进行依赖.

(11)确保你为之建模的抽象概念是类,而不只是对象扮演的角色。p23

(12)在水平方向上尽可能统一地分布系统功能,也即:按照设计,顶层类应当统一地共享工作。p30

(13)在你的系统中不要创建全能类/对象。对名字包含Driver、Manager、System、Susystem的类要特别多加小心。p30
规划一个接口而不是实现一个接口。

(14)对公共接口中定义了大量访问方法的类多加小心。大量访问方法意味着相关数据和行为没有集中存放。p30

(15)对包含太多互不沟通的行为的类多加小心。p31
这个问题的另一表现是在你的应用程序中的类的公有接口中创建了很多的get和set函数。

(16)在由同用户界面交互的面向对象模型构成的应用程序中,模型不应该依赖于界面,界面则应当依赖于模型。p33

(17)尽可能地按照现实世界建模(我们常常为了遵守系统功能分布原则、避免全能类原则以及集中放置相关数据和行为的原则而违背这条原则) 。p36

(18)从你的设计中去除不需要的类。p38
一般来说,我们会把这个类降级成一个属性。

(19)去除系统外的类。p39
系统外的类的特点是,抽象地看它们只往系统领域发送消息但并不接受系统领域内其他类发出的消息。

(20)不要把操作变成类。质疑任何名字是动词或者派生自动词的类,特别是只有一个有意义行为的类。考虑一下那个有意义的行为是否应当迁移到已经存在或者尚未发现的某个类中。p40

(21)我们在创建应用程序的分析模型时常常引入代理类。在设计阶段,我们常会发现很多代理没有用的,应当去除。p43

(22)尽量减少类的协作者的数量。p52
一个类用到的其他类的数目应当尽量少。

(23)尽量减少类和协作者之间传递的消息的数量。p55

(24)尽量减少类和协作者之间的协作量,也即:减少类和协作者之间传递的不同消息的数量。p55

(25)尽量减少类的扇出,也即:减少类定义的消息数和发送的消息数的乘积。p55

(26)如果类包含另一个类的对象,那么包含类应当给被包含的对象发送消息。也即:包含关系总是意味着使用关系。p55

(27)类中定义的大多数方法都应当在大多数时间里使用大多数数据成员。p57

(28)类包含的对象数目不应当超过开发者短期记忆的容量。这个数目常常是6。p57
当类包含多于6个数据成员时,可以把逻辑相关的数据成员划分为一组,然后用一个新的包含类去包含这一组成员。

(29)让系统功能在窄而深的继承体系中垂直分布。p58

(30)在实现语义约束时,最好根据类定义来实现。这常常会导致类泛滥成灾,在这种情况下,约束应当在类的行为中实现,通常是在构造函数中实现,但不是必须如此。p60

(31)在类的构造函数中实现语义约束时,把约束测试放在构造函数领域所允许的尽量深的包含层次中。p60

(32)约束所依赖的语义信息如果经常改变,那么最好放在一个集中式的第3方对象中。p60

(33)约束所依赖的语义信息如果很少改变,那么最好分布在约束所涉及的各个类中。p60

(34)类必须知道它包含什么,但是不能知道谁包含它。p61

(35)共享字面范围(也就是被同一个类所包含)的对象相互之间不应当有使用关系。p61

(36)继承只应被用来为特化层次结构建模。p74

(37)派生类必须知道基类,基类不应该知道关于它们的派生类的任何信息。p74

(38)基类中的所有数据都应当是私有的,不要使用保护数据。p75
类的设计者永远都不应该把类的使用者不需要的东西放在公有接口中。

(39)在理论上,继承层次体系应当深一点,越深越好。p77

(40)在实践中,继承层次体系的深度不应当超出一个普通人的短期记忆能力。一个广为接受的深度值是6。p77

(41)所有的抽象类都应当是基类。p81

(42)所有的基类都应当是抽象类。p82

(43)把数据、行为和/或接口的共性尽可能地放到继承层次体系的高端。p85

(44)如果两个或更多个类共享公共数据(但没有公共行为),那么应当把公共数据放在一个类中,每个共享这个数据的类都包含这个类。 p88

(45)如果两个或更多个类有共同的数据和行为(就是方法),那么这些类的每一个都应当从一个表示了这些数据和方法的公共基类继承。 p89

(46)如果两个或更多个类共享公共接口(指的是消息,而不是方法),那么只有他们需要被多态地使用时,他们才应当从一个公共基类继承。 p89

(47)对对象类型的显示的分情况分析一般是错误的。在大多数这样的情况下,设计者应当使用多态。p89

(48)对属性值的显示的分情况分析常常是错误的。类应当解耦合成一个继承层次结构,每个属性值都被变换成一个派生类。 p96

(49)不要通过继承关系来为类的动态语义建模。试图用静态语义关系来为动态语义建模会导致在运行时切换类型。p97

(50)不要把类的对象变成派生类。对任何只有一个实例的派生类都要多加小心。p99

(51)如果你觉得需要在运行时刻创建新的类,那么退后一步以认清你要创建的是对象。现在,把这些对象概括成一个类。 p103

(52)在派生类中用空方法(也就是什么也不做的方法)来覆写基类中的方法应当是非法的。p103

(53)不要把可选包含同对继承的需要相混淆。把可选包含建模成继承会带来泛滥成灾的类。p108

(54)在创建继承层次时,试着创建可复用的框架,而不是可复用的组件。p112

(55)如果你在设计中使用了多重继承,先假设你犯了错误。如果没犯错误,你需要设法证明。p120

(56)只要在面向对象设计中用到了继承,问自己两个问题:(1)派生类是否是它继承的那个东西的一个特殊类型?(2)基类是不是派生类的一部分?p121

(57)如果你在一个面向对象设计中发现了多重继承关系,确保没有哪个基类实际上是另一个基类的派生类。p122

(58)在面向对象设计中如果你需要在包含关系和关联关系间作出选择,请选择包含关系。p123

(59)不要把全局数据或全局函数用于类的对象的薄记工作。应当使用类变量或类方法。p140

(60)面向对象设计者不应当让物理设计准则来破坏他们的逻辑设计。但是,在对逻辑设计作出决策的过程中我们经常用到物理设计准则。 p149

(61)不要绕开公共接口去修改对象的状态。p164

 
2009年07月18日 11:03
所谓汉化软件就是如果软件程序本身为英文、日文、简体字等等的外国语系,但因为不是每个人都看的懂英文,都看的懂日文,在语言的使用上就有很多的差别,所以使得国人在使用或学习该软件时,特别是一些计算机的初学者,一看到是英文软件,那更是不想去学习,在使用上非常不方便也非常的惧怕。于是国内就有很多热心的网友,将这些外国语系的软件翻译成为中文语系,并且制作成升级 (PATCH) 档的方式,散布给网友使用。
现在的汉化软件和汉化补丁是越来越多了,你肯定也想自己汉化一些软件试试吧。肯定你又会以为这是很麻烦或者很难的事情,只有高手才会做,其实并不是这样,你也完全可以自己汉化一些软件,有些方法还是很简单的,不需要设计到编程的知识。不相信,不相信就听我下面给你介绍三种方法,保证你看完后,你也能汉化一些平常见的软件了。(哎,我把胸口都拍痛了)
第一种方法:
直接修改源二进制的代码,不要紧张,也不要被吓倒,很简单的。这里需要用到一个二进制代码查看器,如果你没有,我推荐你用一个名字为Ultra Edit的编辑器,相信你已经用过这个编辑器,(没有用过?没有用过也不要紧,往下看!)这个软件比Windows自带的记事本的功能强大许多,用法上倒没有什么复杂的地方,至于具体好在哪里,我就不说了,呵呵,可以自己看看专门介绍它的软件。比如说,我们要汉化一个英文软件,就比如汉化Turbo C吧,把菜单中的“File”汉化成中文的“文件”。用此编辑器打开TC的可执行文件tc.exe,当然啦,在做这之前,你要先备份好你要操作的文件,免得到时候没有汉化成功,倒弄坏了文件,回不来了。打开以后,就可以看到它的原二进制代码文件。这时候,你选择查找功能。从二进制中查找到“file”,找倒后,将它修改成“文件”,然后关闭,执行这个文件,看看是不是已经汉化了。当然,这次你找到的不一定就是你要汉化的菜单,不一定会成功。这就需要反复实验了。
这类方法比较累,并且也不一定准确。这种方法现在也基本没有人使用了。
第二种方法:
这种方法是比较简单的一种,但这种方法只能适用于带有语言选择的软件,这样的软件不是很多,只能是偶尔逮着一个,方法很简单,找到它的语言选择文件夹,里面会有各个语言的选择文件,比如FlashGet的language目录下面有三十几个国家的语言版本。这里面已经有中国的了,假如你想新建一个的话,则也可以用记事本按照它的格式建立一个语言版本。提供给大家的一个思路就是将它的原语言版本复制一个后,用记事本打开,然后按照它的格式修改,将它的内容换成你的内容,注意要一行一行地换,如果你把两行弄到一行去了,这就可能会产生错误了。换完后,你也就已经汉化了这个软件了。
这种方法用途不是很大,一般的多语言版本的程序都有中文的语言版本,不需要你的汉化了。
第三种方法:
好的方法当然留在最后讲,这种方法是汉化者们经常用的一种,那就是修改文件的资源文件。我们知道,用VC和DEPHI编译成的软件都有资源文件。高手呢,就是打开VC,直接修改内核,而我们嘛,就不必掌握这些复杂的方法了,这里给大家介绍一个简单的方法,用eXeScope软件修改,特别的简单。(没有听说过?那没有关系,网络学院里面有教程的)像这类的软件还有很多,不过这个历史比较长,使用也非常的简单。就给大家介绍它了。比如我们要汉化OICQ,当然这本来就是中文版了,不需要汉化,没有关系,这里只是给大家演示一下汉化的过程而已。(要详细了解eXeScope,有专门的文章介绍)
启动eXeScope,选择文件菜单,再选择打开,打开QQ的可执行文件。这时候左边的资源栏目里面就会出现该文件的全部资源,包括什么头部文件,导入的动态连接库,以及它所用到的资源文件。而资源文件,就是我们汉化时要终点修改的内容。从资源中间选择菜单(一般汉化就是汉化菜单和对话框)当菜单栏目展开以后,你可以看到右边的栏目里面有该菜单的全部内容了,这时候,只需要你自己改动就可以了,将各个菜单的名字都改成你所要的名字就可以了,比如说要是“File”,你讲它改成“文件”就可以了。注意的是“&”这个符号,编过程序的人应该知道,这个是不能动的,如果你不知道意思,只要记住,这个符号的意义是:这个符号后面紧跟的字母是这个菜单的快捷键,就像记事本的菜单“文件(F)”那么这个F就是快捷键,最好不要删除掉。比如说有个菜单为:“&Edit”,那么你换的时候,就不能把快捷键去掉,把它写成“(&E)编辑”,就可以了。这是一个要注意的地方。
汉化还包括汉化对话框,同样从左边资源树中点开对话框,从右边就可以看到各个具体的标签与空间的名称了,只需要将各控件显示的文字改过来就可以了,按下F8键,就可以可视化地进行修改了。将修改后的文件保存就可以了(在编辑菜单中有“保存修改”项)。你运行一下你刚才修改过的文件,可以看到修改后的效果了。
当然啦,eXeScope的功能远不止这一些,但汉化是非常好的一个功能。*_*
 
2009年04月14日 22:51

新闻来源:blogof.francescomugnai.com
在 Web 中嵌入图形图表的技术越来越丰富,我们可以选择 JavaScript 库,CSS,Flash,Silverlight,PHP 库,服务器端的组件,也可以选择 Google Chart API 这样的 Web 服务。本文介绍了25个在 Web 中嵌入图形图表的免费资源。

JS Charts (基于 JavaScript 的图表生成工具)

Protovis (可视化 javaScript 图表生成工具)

Visifire (基于 Silverlight 和 WPF 的开源图表组件)

pChart (PHP图表类库框架

Ejschart (Javascript)

XML/SWF Charts

Chronoscope (开源)

Open Flash Chart 2

FusionCharts Free

JFreeChart (flash)

Flare (Flash ActionScript 库)

Google Chart API

Google Chart Generator

Timeplot (基于 DHTML 的 AJAX 饰件)

CSS Chart Generator (基于 CSS 的即时 Web 图表生成)

YUI Library

PlotKit (JavaScript 图表库)

Flotr (基于 Prototype框架的图表类库)

Rapha?l (JavaScript library)

Protochart (开源类库,基于 Prototype 和 Canvas)

Bluff (Rubby 下的 Gruff 图表类库的 JavaScript 移植)

Pure Css Line Graph (纯粹基于 CSS 的线形图)

Pure Css Data Chart

CSS Stacked Bar Graphs

Illustrator tutorial

 
2009年01月14日 18:42

1、 软件产品的成熟度

§ SAP:经过近30年与全球大企业用户的合作,SAP系统积累了大量先进企业的业务管理流程。对于用户来说,只需根据在系统中挑选适当的业务流程,在软件中进行配置。而对软件的二次开发工作量极少,这就保证了用户能够把主要的精力都花在企业业务流程的优化上,真正起到上一套系统,管理提高一个层次的作用。

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

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

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

§ SAP:作为ERP系统的重要组成部分,SAP花了2年的时间进行汉化和按照中国政府的人事管理要求进行本地化,使得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 整个系统基于一个统一的数据库,并且共享统一的数据模型。企业内所有的用户都可以根据自己的角色和权限对系统中的数据进行不同维度的分析。而SAPERP、供应链、客户关系管理、数据挖掘等应用系统分别构建在不同的数据库上,不同系统间的数据模型也不相同,这使得各系统之间的数据共享变得非常困难或者不可能。

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软件的应用层是使用ABAP语言编写的程序,ABAP是比较复杂和只有SAP软件使用的语言,比较难掌握,又由于其只能在SAP的软件中才能发挥用途,掌握的人也很少. IT专业人员学习它的积极性也不高. SAP系统在与外界交换数据时, 其接口程序也要求用ABAP语言来编写,具体是用ABAP语言中的函数来向系统中导入数据,其对数据的格式要求也很高,要求的数据必须是带分格符的文本文件。SAP的这些做法导致其软件系统在同第三方软件集成上远远落后于ORACLE,同时这些做法也阻碍了其自生软件的进一步发展,这也是SAPERP与CRM不能完全集成的原因之一。

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

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

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

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

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

实施问题:

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

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

  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。

 
   
 
 
文章存档
 
     
 
最新文章评论
  

很及时,谢谢!
 

回复leader20:没有
 

这个跟django版本有关系吗?
 

装了n回,才找到这个
 

你爱的我也爱
   
帮助中心 | 空间客服 | 投诉中心 | 空间协议
©2012 Baidu