引用Cacheman @ 2005-08-21 14:27)

1) "为什么不能把电子病历转移到关系型数据库上"
有这个必要吗?
我们讨论来讨论去,关于Cache和电子病历 的关系,目前国内做的好的电子病历60%基于Cache.你怎么还考虑"为什么不能把电子病历转移到关系型数据库上"?看样子,我们工作没做好.
如果你的想法成立,还不如直接用关系型数据库开发电子病历.
2)"全部采用cache，可能还有待评诂，或者现实中可行性有多大呢？"
去安贞医院看看
3)"面向对象数据库比面向关系数据库可能技术更先进？从概念处来讲是这样，从实际上是不是也有可能出现另外的情况呢？"
不明白你的意思.没看懂.
4)"我们要做的是，cache到底优点在哪里？弱点在哪里？怎样在系统开发中体现优点，克服弱点，从而创造出优秀的产品，让软件商带动cache的应用，这个应该是你们的出发点吧？"
这个已经讨论了很多了,看看我们前面的贴子或网站,或者挂电话到公司:021-5665 4986.

我总结一下您的意思：1，cache不管在那个方面都比关系型数据库先进。

2，开发电子病历就一定要基于cache。

3， 关系型数据库上就一定不能开发出好的电子病历，原因是国内好的电子病历60%基于cache。

4，医院信息系统应该全部转移到cache数据库上来。

对吗？

Caché是被定义为后关系数据库, 它既提供与RDMBS的SQL相一致的QUERY功能, 又可以 creating Objects. Caché 与目前广泛应用的关系数据库最大的区别是它的面向对象的数据访问层面(data access layer). 它的GLOBAL DATA STRUCTURE 实际上是实行多级树枝样数据存贮, 这与MUMPS完全一致. 举例如下: Patient object 实际是贮存为
^PATIENT(1, “PT AAA”, …)  通过更深的树枝分层, 涵盖病人的姓名,性别,出生日等等..
^PATIENT(2, “PT BBB”, ….)
^PATIENT(3, “PT CCC”,….)
^PATIENT(“B”,”PT AAA”,1)  通过B 或者其他CROSSING INDEX, 来进行侧重于不同DATA的indexing
^PATIENT(“B”,”PT BBB”,2)
^PATIENT(“B”,”PT CCC”,3)
程序可以直接访问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 渐渐走向沉寂.
因为Caché的优点CacheMan已经提到许多了, 我简单的说几点它的不足:
1.因为Caché是强调面向对象开发方式, 对于RDBMS DEVELOPER来说, 很容易陷入用OBJECT-ORIENTED形式来描述DATA LAYER而意识不到.
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的方法.
3.SQL RDBMS 有许多VENDORS 可供比较和选择, 如果SYSTEM 选择了Caché, 意味着系统将要于INTERSYS 成终身伴侣, 因为INTERSYS是唯一的选择. 而从Caché转移到RDBMS 几乎意味着重作一个新系统.
4.要充分利用Caché, 对MUMPS 的充分了解是必要的. MUMPS 人才的缺乏对Caché的应用也造成了障碍.

对于有兴趣了解MUMPS 的朋友, 可以不妨VISIT: http://www.sanchez-gtm.com/, GT.M 是一个基于LINUX的OPEN-SOURCE MUMPS 免费数据管理平台, 可以从SOURCE FORGE获得, 个人认为它可以与Caché相媲美.

引用medsoft @ 2005-08-21 09:58)

我总结一下您的意思：1，cache不管在那个方面都比关系型数据库先进。

2，开发电子病历就一定要基于cache。

3， 关系型数据库上就一定不能开发出好的电子病历，原因是国内好的电子病历60%基于cache。

4，医院信息系统应该全部转移到cache数据库上来。

对吗？

我觉得你的这几句总结太绝对，有点误导。即误导读者，也误导读者对我的理解。恕我直言，有点像我小时候判断一个人一样，要么是好，要么是坏。世界上很少有纯白和纯黑的，大部分是介于白和黑之间的。我本人是Cache坚决的拥护者，但不可能让别人这么去理解Cache. 任何数据库都有自己的特点，只不过在开发应用哪个更好的问题。如果一个公司在开发系统，例如为一家小医院开发PACS系统，没有遇到数据库的瓶颈问题，那就不需要用　Ｃａｃｈｅ。

我的理解：
1）世界是多维的， 多对多。关系型数据库处理的是1对1，Cache处理的是1对多。
如果数据关系本身不复杂，例如就是1对1，关系型数据库就是最佳的处理方式。但如果是海量复杂数据，用Cache更好。我们目前有诚意的合作伙伴，（到目前为止，都是为大型医院开发电子病历和数据挖掘，分析，决策系统），他们大多数原来用过关系型数据库，遇到了困难，才来找我们，看到Cache的好处后，才使用Cache。有些公司已开始只做平行数据迁移，但最后发现最后还是直接用Cache开发好。所以什么系统用Cache,什么系统用关系型数据库，要看你的想法和需求，而不能笼统地说,电子病历，CIS,医保系统等等一定用Cache,PACS,LIS一定用关系型数据库。
Cache和关系型数据库一样是工具，你必须得知道你要做什么事，然后选择用哪一个工具。所以了解需求和工具的功能是前提条件。
我看怎么能最好地沟通？我建议这么做:
a) Cache的功能和特性，请看http://www.intersystems.cn/cache/technology/fc.html
b) 了解你的需求,这个得你自己努力了
c) 结合a)b),比较Cache和关系型数据库如何不同地实现需求,挂电话给我们,谈一下比这么兜圈子好.
2）１１楼的quanta写的很好，建议你去看看。

有什么我理解不对的地方,请谅解.

引用medsoft @ 2005-08-21 09:47)

怎么叫“没有真正摸过cache”？我也不想解释太多，我是2003年收到cache的试用版，曾试图翻译cache的帮助文件。试图基于cache做一些开发工作，但后来因为一些原因放弃了。我现在的电脑上也还装有cache.

我不想说太多，因为我对cache也算是门外汉吧，但我想说我用MSSQL或ORACLE等更没有困难。

我是一个自由的思考者，可以不受约束，但站在商业的立场，选择总是要综合多种因素考虑，而肯定不是某某人说这个软件很好，有很多优势就一定会拿来用，您说对吗？

1)Cache需要重新学,这是事实.这也是它推广起来困难的地方.

2) "我是一个自由的思考者，可以不受约束，但站在商业的立场，选择总是要综合多种因素考虑，而肯定不是某某人说这个软件很好，有很多优势就一定会拿来用，您说对吗？"
我举双手赞成.

首先我想声明，我不懂编程。 但作为CIS项目实施和管理者，我接触过Relational DB, 也接触过Cache.

个人体验是，Cache 最大的优点是运算快，而缺点包括扩展困难（lack of scalability), 维护困难（high requirment of manual updates with changes), 搜寻报告困难（hard to query & report). 除此之外，Cache 的 个体版权费（individual licensing cost） 也可能成为应用的一个障碍。

欢迎讨论。

关键的一点还是不能抛开当前和将来的需求（自己总觉得这怎么有点像废话）？

引用Cacheman @ 2005-08-22 00:29)

我觉得你的这几句总结太绝对，有点误导。即误导读者，也误导读者对我的理解。恕我直言，有点像我小时候判断一个人一样，要么是好，要么是坏。世界上很少有纯白和纯黑的，大部分是介于白和黑之间的。我本人是Cache坚决的拥护者，但不可能让别人这么去理解Cache. 任何数据库都有自己的特点，只不过在开发应用哪个更好的问题。如果一个公司在开发系统，例如为一家小医院开发PACS系统，没有遇到数据库的瓶颈问题，那就不需要用　Ｃａｃｈｅ。

我的理解：
1）世界是多维的， 多对多。关系型数据库处理的是1对1，Cache处理的是1对多。
如果数据关系本身不复杂，例如就是1对1，关系型数据库就是最佳的处理方式。但如果是海量复杂数据，用Cache更好。我们目前有诚意的合作伙伴，（到目前为止，都是为大型医院开发电子病历和数据挖掘，分析，决策系统），他们大多数原来用过关系型数据库，遇到了困难，才来找我们，看到Cache的好处后，才使用Cache。有些公司已开始只做平行数据迁移，但最后发现最后还是直接用Cache开发好。所以什么系统用Cache,什么系统用关系型数据库，要看你的想法和需求，而不能笼统地说,电子病历，CIS,医保系统等等一定用Cache,PACS,LIS一定用关系型数据库。
Cache和关系型数据库一样是工具，你必须得知道你要做什么事，然后选择用哪一个工具。所以了解需求和工具的功能是前提条件。
我看怎么能最好地沟通？我建议这么做:
a) Cache的功能和特性，请看http://www.intersystems.cn/cache/technology/fc.html
b) 了解你的需求,这个得你自己努力了
c) 结合a)b),比较Cache和关系型数据库如何不同地实现需求,挂电话给我们,谈一下比这么兜圈子好.
2）１１楼的quanta写的很好，建议你去看看。

有什么我理解不对的地方,请谅解.

我看到了您的诚意，谢谢您能花这么多时间解释，我总结确实太绝对了！

您的真诚也会打动很多人！

帮助别人作出正确的选择，也会为自己赢得更大的成功，这样ISC更会成为一个伟大的公司。

????????????
我的观点是:
1)面向对象的数据库要比关系型数据库好.
2)尤其在电子病历和挖掘方面, Cache的树状结构非常适合。
????????????

????????????
我的理解：
1）世界是多维的， 多对多。关系型数据库处理的是1对1，Cache处理的是1对多。
????????????

面向对象的数据库要比关系型数据库好？你是不是用了最昂贵的机器呀？RDMS的行锁、表锁、sharepool、SGA、rollback segment技术，有几个在面向对象的数据库中体现？索引的方式想必两者的机理也不一样吧，对于遍历、冒泡等方式，面向对象的数据库怎么做？工作效率差多少，你自己算过吗？

电子病历为什么就不能用文件服务器体系呢？文案管理最牛的是Exchange＋WEB和Domino凭什么Cache最好？

挖掘的宗师BO、SAS你忘掉了还是不知道？数据的旋转、切片、二级提取、三级提取、你的Cache能满足多少？

关系数据库是1对1？！那foreign Key拿来做什么的？别说1对1，用点fucntion和procedure，关系数据库就是多对多也能玩出来。

Cache不过是将Archtecture的技术与RDMS结合的产物；跟单纯的DB根本不在一个比较的基准！将他与IBM的对HIS二次开发工具放在一起比比吧。

海量复杂数据的数据挖掘系统。。。请问与你们合作的是哪一家？我不懂Cache。但希望Cache的优秀不在于表面的称述，还是贴个方案上来罢。

此帖由 drewlee 在 2005-08-22 20:01 进行编辑...

引用quanta @ 2005-06-20 17:29)

fancycn，
看的出来，你应该有很深的技术背景。我们用不着争论到底哪个数据库更好，确实目前在一些（甚至是大部分）的应用中数据模型还相当简单，但是这不意味着用户没有更深层次的需要。随着现代管理制度的不断深入，对相应的应用软件的要求也会越来越高。到底哪个数据库更适合你，只有用了才知道。我知道有人不喜欢绑定在一家厂商上，怕有风险，说句不太好听的，国内的大多数公司倒闭100次，这些系统级的公司也倒不了一次，怕什么啊。
举个例子，请用OR mapping的工具实现人类家族谱的数据模型，我只要求可以实现上下查到祖孙3代，以及直系、旁系3代。

"举个例子，请用OR mapping的工具实现人类家族谱的数据模型，我只要求可以实现上下查到祖孙3代，以及直系、旁系3代。" 感觉quanta说得太绝对, 似乎只有cache才能做到. 有兴趣的朋友,可以访问下面的link:
http://www.hci.utah.edu/groups/ppr/index.html
UPDB最深实现了跨越九个代系的DATA REPRESENTATION, 并且有多篇在TOP专业杂志发表的文章是通过对UPDB进行 DATA MINING所得的数据进行科学统计与分析产生的.

顺便提一下, UPDA 是基于SYBASE, 目前正向SQL SERVER CONVERTING...

The Utah Population Database (UPDB) is a rich source of information for genetic, epidemiological, demographic and public health studies. For 30 years, researchers have used this resource to identify and study families that have higher than normal incidence of cancer or other diseases, to analyze patterns of genetic inheritance and to identify specific genetic mutations. Demographic studies have observed and analyzed the trends in the fertility transition and changes in mortality patterns for both infants and adults. The UPDB is the only such database of its kind in the US and one of few such resources in the world. The central component of UPDB is an extensive set of Utah family histories, in which family members are linked to demographic and medical information. The UPDB also includes diagnostic records on cancer, cause of death, and medical details associated with births. The UPDB provides access to almost 9 million records and supports over 55 research projects. These data can only be used for biomedical and health related research.

我认为这个例子不错啦。
以递归算法只能实现祖孙N代，以及直系、旁系N代，控制在3代我做不到。但不知Cache用什么数据结构实现？

希望jdli能把算法详细列一下。

引用drewlee @ 2005-08-22 11:17)

????????????
我的观点是:
1)面向对象的数据库要比关系型数据库好.
2)尤其在电子病历和挖掘方面, Cache的树状结构非常适合。
????????????
????????????
我的理解：
1）世界是多维的， 多对多。关系型数据库处理的是1对1，Cache处理的是1对多。
????????????
面向对象的数据库要比关系型数据库好？你是不是用了最昂贵的机器呀？RDMS的行锁、表锁、sharepool、SGA、rollback segment技术，有几个在面向对象的数据库中体现？索引的方式想必两者的机表面的称述，还是贴个方案上来罢。

这儿评论的人对Cache了解程度的区别太大.没办法一一回答.
既然不懂Cache,这么评价是否有点不科学?
建议先看看http://www.intersystems.cn/cache/educat...n-training.html再评价也不迟.

引用jdli @ 2005-08-21 16:23)

4.要充分利用Caché, 对MUMPS 的充分了解是必要的. MUMPS 人才的缺乏对Caché的应用也造成了障碍.
对于有兴趣了解MUMPS 的朋友, 可以不妨VISIT: http://www.sanchez-gtm.com/, GT.M 是一个基于LINUX的OPEN-SOURCE MUMPS 免费数据管理平台, 可以从SOURCE FORGE获得, 个人认为它可以与Caché相媲美.

有多少医疗卫生行业的成功案例吗?
在中国有技术支持吗?
有中文资料吗?

CacheMan，？？？中的内容是我引用的是你的原话而已。

你们的网站我看过勒。

Cache的设计思路是不错的。但是我看不出网站和你列出的Cache能覆盖多少的系统评价的性能指标。

你的知识面倾向于软件，系统的性能可不仅仅只包括软件。希望你“能”回答Cache数据库的容错、并发、事务、负载等解决的原理和设计。HIS厂商败在构架、DB设计上的不在少数，往往一个Cluster就搞的有着优雅界面的App灰头土脸。没有量化的东西，我觉得是不可信的。。。。。

再者，别忘勒，IT里优秀的东西多着呢。不要眼里只有一个Cache。

引用drewlee @ 2005-08-24 10:31)

CacheMan，？？？中的内容是我引用的是你的原话而已。
你们的网站我看过勒。
Cache的设计思路是不错的。但是我看不出网站和你列出的Cache能覆盖多少的系统评价的性能指标。
你的知识面倾向于软件，系统的性能可不仅仅只包括软件。希望你“能”回答Cache数据库的容错、并发、事务、负载等解决的原理和设计。HIS厂商败在构架、DB设计上的不在少数，往往一个Cluster就搞的有着优雅界面的App灰头土脸。没有量化的东西，我觉得是不可信的。。。。。
再者，别忘勒，IT里优秀的东西多着呢。不要眼里只有一个Cache。

你还是挂个电话给我,021-5665 4986, 或发个具体的设计上的问题给info@intersystems.cn
这样我们比较一下原来关系型数据库的解决方案和Cache的解决方案.

"再者，别忘勒，IT里优秀的东西多着呢。不要眼里只有一个Cache"
对不起, 我的眼里只有一个Cache,因为这是我的job.

引用medsoft @ 2005-08-22 05:02)

我看到了您的诚意，谢谢您能花这么多时间解释，我总结确实太绝对了！

您的真诚也会打动很多人！

帮助别人作出正确的选择，也会为自己赢得更大的成功，这样ISC更会成为一个伟大的公司。

ISC在中国的路还很长.目前我们还在起步阶段,谢谢你对Cache的兴趣和对我们的支持.