找回密码
 欢迎注册
搜索
热搜: 活动 交友 discuz
楼主: fancycn

关于cache数据库的一些思考!

[复制链接]
发表于 2005-8-18 21:43:07 | 显示全部楼层

关于cache数据库的一些思考!

<!--quote-hykionliu+2005-08-18 08:39--><div class='quotetop'>引用hykionliu &#064; 2005-08-18 08:39)</div><div class='quotemain'><!--quote1-->您可能没有理解我说的误区是什么!
<br>我是说当别人越是质疑的时候,您越是强调cache的好处,而您越是这样努力,有的人因为性格原因和文化背景,他就越会认为cache 肯定有一些不尽人意的地方,自然就会引起他们的研究兴趣,去研究cache 不足之处,从长远来看对cache 是有利的!但您却只强调一面,在cache 的不足方面却极少提及,而这也刺激了我们一些专家的研究兴趣!
<br>您觉得呢?
<br>作为贵公司的合作伙伴,我们非常希望cache 在中国能够得到广泛应用,但在具体应用的时候可能会由于软件开发、数据库本身以及其他因素的影响而使cache 不能体现出他的优越性能!
<br>因此,您作为非常了解cache的专家!我们需要您帮助的就是cache 在什么样的应用环境中会发挥它的卓越性能,反之在什么应用环境中则不能!
<br>凡事强调正反两个方面,通过对比分析,相信大家对cache 一定能有一个比较全面、准确、真实的了解!<!--quote2--></div><!--quote3-->
<br>OK.有道理.
<br>Cache确实有不足的地方, 例如开发界面(技术),我们在国内的品牌,知名度,成功案例,价格模式等等(商务)
<br>但是这儿所讨论的都是关于性能的问题,二维表和多维数组的比较,所以我才发表我的观点
<br>说到底,Cache的好处主要是
<br>1) 树状的多维结构,比二维表更加贴近真实世界。(所以如果数据的结构比较简单,二维表和多维数组的区别就不大,如果你原来用SQL, Oracle就很好,那就继续用,没有必要改成Cache&#039;)。目前,由于国内一些合作伙伴做的是平行数据迁移,所以没办法显示Cache的高性能。
<br>2) 面向对象的编程
<br>3) ECP技术
<br>相信你有这样的感觉.钻研越多,可能每天的感觉都不一样。
<br>
<br>
发表于 2005-8-18 21:58:56 | 显示全部楼层

关于cache数据库的一些思考!

<!--quote-hykionliu+2005-08-18 08:39--><div class='quotetop'>引用hykionliu &#064; 2005-08-18 08:39)</div><div class='quotemain'><!--quote1-->您可能没有理解我说的误区是什么!
<br>我是说当别人越是质疑的时候,您越是强调cache的好处,而您越是这样努力,有的人因为性格原因和文<!--quote2--></div><!--quote3-->
<br>hykionliu, 谢了.
<br>
发表于 2005-8-18 22:19:49 | 显示全部楼层

关于cache数据库的一些思考!

My 2 pence worth, correct me if i am wrong, it is my understanding that cache database is very developer friendly and are well suited for applications that require embedded database. because its OOD approach, it is well suited for ontological development where traditional relational database would fail badly. However, the XML support of newer generation databases e.g. sql2005 and XQuery in large are addressing the issue and in part facilitates semantic data engineering.
发表于 2005-8-19 01:02:57 | 显示全部楼层

关于cache数据库的一些思考!

<p>关于cache的辨论本身是一件很有意义的事,很可惜最后似乎要变成无谓的争吵了,我们都不希望看到这种局面,我也很敬佩cacheman的为人,我同时希望大家能把力量集中到提高中国医院的信息化水平上!</p><p>对数据库的选择是很困难的,特别是cache.我也看过cache的宣传资料,主要宣传是:1,面向对象,2,支持多维数据表,3,速度快,4,维护轻松,5,开发周期短,与C++,JAVA等开发软件结合较好等,这里我想说一点,就是hykionliu说的&ldquo;平行数据迁移&rdquo;,基于关系型数据库的软件也可以使用cache,但基于cache的软件要应用到关系型上去恐怕就很难了吧?</p><p>在医院信息化进展到以CIS为主的第二阶段时,cache的优势可能会显现出来,但这并不能掩盖cache的弱点,我们也希望cache能更加中国化,比如推出中文版啊,改进使用界面啊!</p>
发表于 2005-8-19 08:38:08 | 显示全部楼层

关于cache数据库的一些思考!

一点都没错!我也是随着论坛的辩论和与客户的沟通,不断地丰富着自己对cache的理解!
<br>
<br>我想我们会在不久一系列的cache 培训之后,进一步增进这种理解!从而能够更加快地推动cache在医院信息化过程中的应用!
<br>
<br>如果说我的哪些言辞引起了无谓的争辩,那不是我的初衷,只能说是我的一种罪过了!呵呵!
发表于 2005-8-19 10:09:46 | 显示全部楼层

关于cache数据库的一些思考!

cacheman的认真和执着值得尊敬。<!--editpost--><br><br><br><div><font class='editinfo'>此帖由 jhs1 在 2005-08-18 23:12 进行编辑...</font></div><!--editpost1-->
发表于 2005-8-19 10:14:14 | 显示全部楼层

关于cache数据库的一些思考!

没错!他是一个很敬业的人!!!!
<br>但不知道是不是陈总啊?
发表于 2005-8-20 09:39:17 | 显示全部楼层

关于cache数据库的一些思考!

<!--quote-jhs1+2005-08-19 02:09--><div class='quotetop'>引用jhs1 &#064; 2005-08-19 02:09)</div><div class='quotemain'><!--quote1-->cacheman的认真和执着值得尊敬。<!--quote2--></div><!--quote3-->
<br>1)谢了,这是作为职业经理人必须具备的素质。至于我叫什么,无所谓。只代表公司形象吧。
<br>2)medsoft: "但基于cache的软件要应用到关系型上去恐怕就很难了吧?"
<br>先问一下, 我理解的是否正确?
<br>a) 如果是指在一个医院cache和其他关系型数据库并存,例如,HIS系统是基于sql server的 A公司提供的,而电子病历是海泰提供的基于Cache的,两者之间的交流没有问题。Cache提供了一个和关系型数据库向接口的网关。另外, Cache本身可以用关系型访问。这样如果,A医院的系统基于Oracle,B医院基于Cache,两者的沟通应该没有问题。 Cache要在关系型数据库占主导地位的市场上生存和发展,不对关系型数据库作深入的研究是不行的。
<br>问题在于:终端客户为什么要花钱买2个不同的数据库,付2个维护费。
<br>我们的解决方案是平行数据迁移,把老的方案从关系型数据库换到Cache上来。
<br>b) 如果是指 完全基于Cache开发的,要再换回到关系型上,例如迁移到Oracle上面,这确实很难。问题是有没有这个必要?
<br>i)关系型数据库代替网状数据库(第一代数据库)的时候,还需要将用关系型数据库写的应用再换回网状数据库吗?同样,面向对象的数据库替代关系型数据库,为什么还需要考虑再换回去?
<br>ii) 目前在中国的好的合作伙伴(不包括那些投机的,不做任何Cache开发,就挂名自己也用Cache的开发商),之所以用 Cache,是因为他们以前用关系型数据库开发一个系统遇到了技术困难,而Cache帮他们解决了这个问题。在这种情况下,还考虑换回到关系型数据库有什么意义?
<br>3)learning: Cache最初是从M语言发展来的。M语言当时有一帮公司在支持, Intersystems只是其中之一。 这样认为比较客观一点:Cache继承了M语言的精华,但功能已大大超越了M语言。所以在美国,InterSystems已经不提M语言这个概念了。这和你所写的情况吻合。在中国,我们的认识慢了一步,所以大家先研究M语言,再研究Cache. 其实大可不必这样,最好直接从Cache入门,比较关系型数据库和Cache在你平时碰到的问题中解决方案有什么不一样,这可能才是最好的比较。
<br>“不过答应后来联系我, 让我去他办公室, 邮寄材料跟我, 却忘了.”发个联系地址给contact@intersystems.cn
<br>
<br>
<br>
发表于 2005-8-20 13:32:41 | 显示全部楼层

关于cache数据库的一些思考!

<p><!--quote-Cacheman+2005-08-20 09:39--><div class='quotetop'>引用Cacheman &#064; 2005-08-20 09:39)</div><div class='quotemain'><!--quote1-->&nbsp;<br />2)medsoft: "但基于cache的软件要应用到关系型上去恐怕就很难了吧?" <br />先问一下, 我理解的是否正确? <br />a) 如果是指在一个医院cache和其他关系型数据库并存,例如,HIS系统是基于sql server的 A公司提供的,而电子病历是海泰提供的基于Cache的,两者之间的交流没有问题。Cache提供了一个和关系型数据库向接口的网关。另外, Cache本身可以用关系型访问。这样如果,A医院的系统基于Oracle,B医院基于Cache,两者的沟通应该没有问题。 Cache要在关系型数据库占主导地位的市场上生存和发展,不对关系型数据库作深入的研究是不行的。 <br />问题在于:终端客户为什么要花钱买2个不同的数据库,付2个维护费。 <br />我们的解决方案是平行数据迁移,把老的方案从关系型数据库换到Cache上来。 <br />b) 如果是指 完全基于Cache开发的,要再换回到关系型上,例如迁移到Oracle上面,这确实很难。问题是有没有这个必要? <br />i)关系型数据库代替网状数据库(第一代数据库)的时候,还需要将用关系型数据库写的应用再换回网状数据库吗?同样,面向对象的数据库替代关系型数据库,为什么还需要考虑再换回去? <br />ii) 目前在中国的好的合作伙伴(不包括那些投机的,不做任何Cache开发,就挂名自己也用Cache的开发商),之所以用 Cache,是因为他们以前用关系型数据库开发一个系统遇到了技术困难,而Cache帮他们解决了这个问题。在这种情况下,还考虑换回到关系型数据库有什么意义? <!--quote2--></div><!--quote3--></p><p>您的理解正是我想表达的,您的解答也很合理,您提到的第一种情况正是许多医院面临的现实问题,医院内各种系统来自不同的供应商,而出现多种后台数据库,从您的角度来说是&ldquo;<strong>平行数据迁移,把老的方案从关系型数据库转移到cache上。&rdquo;</strong>这当然是一种方法,但从医院的角度,也可以问&ldquo;为什么不能把电子病历转移到关系型数据库上&rdquo;呢?</p><p>正如您所说的第二种情况,电子病历或其他系统开发用传统关系型数据库了遇到了困难,而使用cache,应该是不能迁移到关系型数据库上的。</p><p>全部采用cache,可能还有待评诂,或者现实中可行性有多大呢?</p><p>面向对象数据库比面向关系数据库可能技术更先进?从概念处来讲是这样,从实际上是不是也有可能出现另外的情况呢?</p><p>我们要做的是,cache到底优点在哪里?弱点在哪里?怎样在系统开发中体现优点,克服弱点,从而创造出优秀的产品,让软件商带动cache的应用,这个应该是你们的出发点吧?</p>
发表于 2005-8-21 14:27:54 | 显示全部楼层

关于cache数据库的一些思考!

<!--quote-medsoft+2005-08-20 05:32--><div class='quotetop'>引用medsoft &#064; 2005-08-20 05:32)</div><div class='quotemain'><!--quote1-->您的理解正是我想表达的,您的解答也很合理,您提到的第一种情况正是许多医院面临的现实问题,医院内各种系统来自不同的供应商,而出现多种后台数据库,从您的角度来说是“<b>平行数据迁移,把老的方案从关系型数据库转移到cache上。”</b>这当然是一种方法,但从医院的角度,也可以问“为什么不能把电子病历转移到关系型数据库上”呢?
<br>
<br>正如您所说的第二种情况,电子病历或其他系统开发用传统关系型数据库了遇到了困难,而使用cache,应该是不能迁移到关系型数据库上的。
<br>
<br>全部采用cache,可能还有待评诂,或者现实中可行性有多大呢?
<br>
<br>面向对象数据库比面向关系数据库可能技术更先进?从概念处来讲是这样,从实际上是不是也有可能出现另外的情况呢?
<br>
<br>我们要做的是,cache到底优点在哪里?弱点在哪里?怎样在系统开发中体现优点,克服弱点,从而创造出优秀的产品,让软件商带动cache的应用,这个应该是你们的出发点吧?<!--quote2--></div><!--quote3-->
<br>1) "为什么不能把电子病历转移到关系型数据库上"
<br>有这个必要吗?
<br>我们讨论来讨论去,关于Cache和电子病历 的关系,目前国内做的好的电子病历60%基于Cache.你怎么还考虑"为什么不能把电子病历转移到关系型数据库上"?看样子,我们工作没做好.
<br>如果你的想法成立,还不如直接用关系型数据库开发电子病历.
<br>2)"全部采用cache,可能还有待评诂,或者现实中可行性有多大呢?"
<br>去安贞医院看看
<br>3)"面向对象数据库比面向关系数据库可能技术更先进?从概念处来讲是这样,从实际上是不是也有可能出现另外的情况呢?"
<br>不明白你的意思.没看懂.
<br>4)"我们要做的是,cache到底优点在哪里?弱点在哪里?怎样在系统开发中体现优点,克服弱点,从而创造出优秀的产品,让软件商带动cache的应用,这个应该是你们的出发点吧?"
<br>这个已经讨论了很多了,看看我们前面的贴子或网站,或者挂电话到公司:021-5665 4986.
<br>
发表于 2005-8-21 14:36:22 | 显示全部楼层

关于cache数据库的一些思考!

To learning: 地址有错,应该是contacts@intersystems.cn   hezuo@intersystems.cn
<br>to Medsoft: 如果我没有想错的话,你虽然看了很多Cache的宣传或一些学习资料,但没有真正摸过Cache.这样来讨论Cache意义不大.只是我的猜想
发表于 2005-8-21 17:47:41 | 显示全部楼层

关于cache数据库的一些思考!

<p><!--quote-Cacheman+2005-08-21 14:36--><div class='quotetop'>引用Cacheman &#064; 2005-08-21 14:36)</div><div class='quotemain'><!--quote1-->to Medsoft: 如果我没有想错的话,你虽然看了很多Cache的宣传或一些学习资料,但没有真正摸过Cache.这样来讨论Cache意义不大.只是我的猜想<!--quote2--></div><!--quote3--><br /></p><p>怎么叫&ldquo;没有真正摸过cache&rdquo;?我也不想解释太多,我是2003年收到cache的试用版,曾试图翻译cache的帮助文件。试图基于cache做一些开发工作,但后来因为一些原因放弃了。我现在的电脑上也还装有cache.</p><p>我不想说太多,因为我对cache也算是门外汉吧,但我想说我用MSSQL或ORACLE等更没有困难。</p><p>我是一个自由的思考者,可以不受约束,但站在商业的立场,选择总是要综合多种因素考虑,而肯定不是某某人说这个软件很好,有很多优势就一定会拿来用,您说对吗?</p>
发表于 2005-8-21 17:58:31 | 显示全部楼层

关于cache数据库的一些思考!

<p><!--quote-Cacheman+2005-08-21 14:27--><div class='quotetop'>引用Cacheman &#064; 2005-08-21 14:27)</div><div class='quotemain'><!--quote1--><br />1) "为什么不能把电子病历转移到关系型数据库上" <br />有这个必要吗? <br />我们讨论来讨论去,关于Cache和电子病历 的关系,目前国内做的好的电子病历60%基于Cache.你怎么还考虑"为什么不能把电子病历转移到关系型数据库上"?看样子,我们工作没做好. <br />如果你的想法成立,还不如直接用关系型数据库开发电子病历. <br />2)"全部采用cache,可能还有待评诂,或者现实中可行性有多大呢?" <br />去安贞医院看看 <br />3)"面向对象数据库比面向关系数据库可能技术更先进?从概念处来讲是这样,从实际上是不是也有可能出现另外的情况呢?" <br />不明白你的意思.没看懂. <br />4)"我们要做的是,cache到底优点在哪里?弱点在哪里?怎样在系统开发中体现优点,克服弱点,从而创造出优秀的产品,让软件商带动cache的应用,这个应该是你们的出发点吧?" <br />这个已经讨论了很多了,看看我们前面的贴子或网站,或者挂电话到公司:021-5665 4986. <br /><!--quote2--></div><!--quote3--><br /></p><p>我总结一下您的意思:1,cache不管在那个方面都比关系型数据库先进。</p><p>2,开发电子病历就一定要基于cache。</p><p>3, 关系型数据库上就一定不能开发出好的电子病历,原因是国内好的电子病历60%基于cache。</p><p>4,医院信息系统应该全部转移到cache数据库上来。</p><p>对吗?</p>
发表于 2005-8-22 00:23:29 | 显示全部楼层

关于cache数据库的一些思考!

Caché是被定义为后关系数据库, 它既提供与RDMBS的SQL相一致的QUERY功能, 又可以 creating Objects. Caché 与目前广泛应用的关系数据库最大的区别是它的面向对象的数据访问层面(data access layer). 它的GLOBAL DATA STRUCTURE 实际上是实行多级树枝样数据存贮, 这与MUMPS完全一致. 举例如下: Patient object 实际是贮存为
<br>^PATIENT(1, “PT AAA”, …) &#61664; 通过更深的树枝分层, 涵盖病人的姓名,性别,出生日等等..
<br>^PATIENT(2, “PT BBB”, ….)
<br>^PATIENT(3, “PT CCC”,….)
<br>^PATIENT(“B”,”PT AAA”,1) &#61664; 通过B 或者其他CROSSING INDEX, 来进行侧重于不同DATA的indexing
<br>^PATIENT(“B”,”PT BBB”,2)
<br>^PATIENT(“B”,”PT CCC”,3)
<br>程序可以直接访问GLOBAL DATA FILE. 例如, 想得到”PT BBB” 的DATA, 可以直接用命令 $O(^PATIENT(“B”,”PT BBB”,0)) 得到病人”PT BBB”的IDENTIFIER 2, 然后直接访问^PATIENT(2, NODE获得所需DATA. 因为可以对数据库进行直接访问,就极大的提高了数据库的PERFORMANCE, 因此号称速度最快的数据库.虽然Caché提供了SQL支持,但我觉得外部输入的SQL仍是被转化为MUMPS相应命令进行GLOBAL DATA 的读存, 相比于数据的直接访问, Caché SQL会牺牲系统的PERFORMANCE. CACHE/MUMPS 的多级树枝样数据存贮的设计直到今日仍有其先进性和合理性, 特别是对于HEALTHCARE 领域的应用. 因为MUMPS 本身就是为满足HEALTHCARE INSTITUTION 的需要量身开发的. 上世纪七八十年代, 是MUMPS应用相对广泛的时候, 原因之一是还没有能满足health care 领域需要的成熟的RDBMS 产品的出现. 随着SQL RDBMS 的逐渐成熟完善及强有力的商业推广, MUMPS 渐渐走向沉寂.
<br>因为Caché的优点CacheMan已经提到许多了, 我简单的说几点它的不足:
<br>1.因为Caché是强调面向对象开发方式, 对于RDBMS DEVELOPER来说, 很容易陷入用OBJECT-ORIENTED形式来描述DATA LAYER而意识不到.
<br>2.因为Caché 提供数据的直接访问和修改,它很容易BREAK DATA INTEGRITY. 例如, 可以用 S ^PATIENT(1,”PT AAA”)=”12345” 来直接修改 ^PATIENT(1,”PT AAA”)的DATA, 如不相应的UPDATE CROSSING INDEX, DATA INTEGRITY WILL BE BROKEN. 而在RDBMS, SQL是唯一的进行数据INTERACTING的方法.
<br>3.SQL RDBMS 有许多VENDORS 可供比较和选择, 如果SYSTEM 选择了Caché, 意味着系统将要于INTERSYS 成终身伴侣, 因为INTERSYS是唯一的选择. 而从Caché转移到RDBMS 几乎意味着重作一个新系统.
<br>4.要充分利用Caché, 对MUMPS 的充分了解是必要的. MUMPS 人才的缺乏对Caché的应用也造成了障碍.
<br>
<br>对于有兴趣了解MUMPS 的朋友, 可以不妨VISIT: <a href="http://www.sanchez-gtm.com/" target="_blank">http://www.sanchez-gtm.com/</a>, GT.M 是一个基于LINUX的OPEN-SOURCE MUMPS 免费数据管理平台, 可以从SOURCE FORGE获得, 个人认为它可以与Caché相媲美.
<br>
发表于 2005-8-22 00:29:11 | 显示全部楼层

关于cache数据库的一些思考!

<!--quote-medsoft+2005-08-21 09:58--><div class='quotetop'>引用medsoft &#064; 2005-08-21 09:58)</div><div class='quotemain'><!--quote1-->我总结一下您的意思:1,cache不管在那个方面都比关系型数据库先进。
<br>
<br>2,开发电子病历就一定要基于cache。
<br>
<br>3, 关系型数据库上就一定不能开发出好的电子病历,原因是国内好的电子病历60%基于cache。
<br>
<br>4,医院信息系统应该全部转移到cache数据库上来。
<br>
<br>对吗?<!--quote2--></div><!--quote3-->
<br>
<br>我觉得你的这几句总结太绝对,有点误导。即误导读者,也误导读者对我的理解。恕我直言,有点像我小时候判断一个人一样,要么是好,要么是坏。世界上很少有纯白和纯黑的,大部分是介于白和黑之间的。我本人是Cache坚决的拥护者,但不可能让别人这么去理解Cache. 任何数据库都有自己的特点,只不过在开发应用哪个更好的问题。如果一个公司在开发系统,例如为一家小医院开发PACS系统,没有遇到数据库的瓶颈问题,那就不需要用 Cache。
<br>
<br>我的理解:
<br>1)世界是多维的, 多对多。关系型数据库处理的是1对1,Cache处理的是1对多。
<br>如果数据关系本身不复杂,例如就是1对1,关系型数据库就是最佳的处理方式。但如果是海量复杂数据,用Cache更好。我们目前有诚意的合作伙伴,(到目前为止,都是为大型医院开发电子病历和数据挖掘,分析,决策系统),他们大多数原来用过关系型数据库,遇到了困难,才来找我们,看到Cache的好处后,才使用Cache。有些公司已开始只做平行数据迁移,但最后发现最后还是直接用Cache开发好。所以什么系统用Cache,什么系统用关系型数据库,要看你的想法和需求,而不能笼统地说,电子病历,CIS,医保系统等等一定用Cache,PACS,LIS一定用关系型数据库。
<br>Cache和关系型数据库一样是工具,你必须得知道你要做什么事,然后选择用哪一个工具。所以了解需求和工具的功能是前提条件。
<br>我看怎么能最好地沟通?我建议这么做:
<br>a) Cache的功能和特性,请看<a href="http://www.intersystems.cn/cache/technology/fc.html" target="_blank">http://www.intersystems.cn/cache/technology/fc.html</a>
<br>b) 了解你的需求,这个得你自己努力了
<br>c) 结合a)b),比较Cache和关系型数据库如何不同地实现需求,挂电话给我们,谈一下比这么兜圈子好.
<br>2)11楼的quanta写的很好,建议你去看看。
<br>
<br>有什么我理解不对的地方,请谅解.
<br>
您需要登录后才可以回帖 登录 | 欢迎注册

本版积分规则

快速回复 返回顶部 返回列表