你用过系统间Cach吗é? 你有什么经验?

缓存是一个独特的野兽,这取决于您如何使用它,然后它可以被描述为无SQL数据库、RDBMS或面向对象数据库。当然,这并不是所有人都能理解的事情,所以要知道每个人的理解方式需要一些解释。

它都是建立在一种称为 MUMPS

这种语言有一种集合类型,一种具有0个或多个已排序键的键/值字典,还有一种数据类型,它有运算符来执行字符串操作,其他运算符来执行数字操作。所有键和值都是该数据类型的实例。

这已经存在很长一段时间了,在此基础上编写的应用程序仍然可以运行。

这种语言早于第一个RDBMS,但后来该语言的实现者增加了RDBMS支持。Cache将SQL(静态或动态)编译成更现代的MUMPS版本,然后驱动存储引擎。如果这听起来很奇怪,其实并非如此——每一个RDBMS都会编译或解释SQL,为它的存储引擎指明方向。

Cache已经发展成为一种面向对象的语言(就像许多其他语言随着时间的推移所做的那样),这意味着现在有两种数据类型,一种是原始类型,另一种是对象类型。对象不能作为键或值直接存储在磁盘上,但可以继承或实现持久性方法。

因此,使用缓存的人可能会使用面向对象的代码、SQL或过程代码,或者随意组合它们。

优点和缺点是什么?

对于运行传统流行性腮腺炎应用程序的人来说,他们几乎别无选择,所以我将关注其他人。

一个很大的缺点是,is的市场份额很小(与其他RDBMS相比,尽管它可以与其他产品相比),而且它的定价与商业RDBMS的定价是一样的(尽管对于它的某些特殊用途,制定一个单独的交易可能要容易得多),因此,需要有一些令人信服的理由来购买它。

另一个问题是,除了Intersystems(供应商)提供的代码库之外,几乎没有其他代码库,这些代码库在规模上不可能与.NET或Java之类的东西竞争。

一个很大的优势是,缓存对象脚本(现代流行语语言)比通常在数据库中使用的语言多得多。数据库中的业务逻辑越多,这就越有优势。

实际上,如果您将缓存用于业务逻辑,那么它的大部分优点都会出现。将数据库和业务逻辑结合起来更简单,更容易获得高性能,并且在环境支持这么多的情况下不会特别导致长期维护问题。

在缓存中结合数据库和业务逻辑的缺点是,移植两者都非常困难,通常业务逻辑是用自由语言编写的,运行它不需要任何类型的许可证。在这里,您几乎处于同一条船上,就好像您的业务逻辑在TSQL中一样,只是移植起来更加困难。

不过,如果你同意的话,很多东西都很可爱。没有ORM-商业或手工编码。SQL被编译成可以查看的代码(它的生成优化了速度而不是可读性,变量名可以是类似于“T32”的东西,但是如果必须的话它仍然可读),甚至是单步执行或断点。编写SQL游标的成本非常低。实际上,您可以编写面向对象的代码。它的解释,所以它更容易迅速发展。如果您想提高速度,可以关闭事务,不使用SQL。

我也发现它很容易管理。在我的大部分经验中,没有DBA这样的东西-你只是不需要。

系统间的缓存可以定义为面向对象的数据库。

我认为它是一个带有面向对象脚本引擎的常规RDBMS数据库。Oracle有存储过程,Cache有对象脚本。

有很强的面向对象背景的人可能更喜欢使用ObjectScript。

以防你没看到,给你 their documentation

它不是RDBMS的设计。它是对象数据库。您可以使用sql接口,查看来自传统RDBMS的数据。

数据存储在树中,他们称之为globals。你储存的东西都是树。它们具有对象访问权限,实际上数据库中的对象是您语言中的对象(Objectscript,我认为它们支持java)。 数据中存在真正的继承(globals,称之为table是不正确的)。所以不需要hibernate/orm/jpa/。。。什么东西。