caching - 您使用过IntersystemsCaché吗？你有什么经验？

Question

我碰到过一些声称使用CacheDB而不是经过验证的RDBMS的说法。但是我不明白它比RDBMS更好吗？如果是这样，为什么要在它们前面加上Cache？

是RDBMS还是Caché服务器？您可以在项目中编写有关用例的简短说明吗？

Answer 1

缓存是一种独特的野兽，具体取决于您如何使用它，然后可以将其描述为No SQL数据库，RDBMS或面向对象的数据库。当然，对所有人而言，这并不是万能的，因此，了解每种事物的方式需要一些解释。

所有这些都建立在称为MUMPS的关系前程序语言的基础上（可怕的营销名称也对Googling来说很糟糕，因此现在他们只使用对Googling来说很糟糕的Cache）。该语言包括将数据作为本机命令持久化的操作，因此可以优化持久化引擎而不影响应用程序代码。

该语言具有一种集合类型，具有0个或多个排序键的键/值字典以及一种数据类型，该数据类型具有用于执行严格操作的运算符和用于其他操作的运算符。所有键和值都是该数据类型的实例。

这已经有很长的时间了，在此之上编写了数十年的应用程序仍然可以运行。

该语言早于第一个RDBMS，但该语言的后续实现者增加了RDBMS支持。缓存将SQL（静态或动态）编译为MUMPS的更新版本，然后驱动存储引擎。如果听起来很奇怪，那不是真的-每个RDBMS都会将SQL编译或解释为存储引擎的指令。

缓存已经发展成为一种面向对象的语言（就像许多其他语言一样，随着时间的流逝），这意味着现在有2种数据类型，原始的是数据类型，再加上对象类型。对象不能直接作为键或值存储在磁盘上，但可以继承或实现持久性方法。

因此，使用Cache的人们可能会使用面向对象的代码，SQL或过程代码，或者根据需要进行组合。

优点和缺点是什么？

对于运行旧版MUMPS应用程序的人来说，他们几乎别无选择，因此我将重点关注其他所有人。

一个很大的缺点是它的市场份额很小（与其他RDBMS相比，尽管可以与其他产品进行比较），并且价格与商业RDBMS处于同一水平（尽管很容易制定出一个个体）处理特定的特殊用途），因此需要某种令人信服的理由来购买它。

而且，较小的市场份额意味着开发商的市场较小。另外，使用它的不同方式意味着并非所有的Cache开发人员都适合所有项目-在过去20年中维护旧版（从流行结构化编程之前）的应用程序的人可能不太擅长将Cache用于面向对象的Web应用程序。

另一个问题是，除了系统间（供应商）提供的代码库外，几乎没有其他代码库，并且这些库可能无法与.NET或Java之类的产品竞争。

一个很大的优点是，缓存对象脚本（现代MUMPS语言）比您通常在数据库中获得的语​​言多得多。您在数据库中拥有的业务逻辑越多，这就是一个优势。

实际上，恕我直言，如果您将Cache用于您的业务逻辑，则它的大多数优点都会显现出来。将数据库和业务逻辑结合起来非常简单，更容易获得高性能，并且当环境如此支持时，不会特别导致长期维护问题。

在Cache中将数据库和业务逻辑结合在一起的缺点是，移植两者都将非常困难，并且通常您的业务逻辑是用自由语言编写的，并且您不需要任何类型的许可证即可运行它。在这里，您几乎就像在TSQL中使用业务逻辑一样，只是更难移植。

如果你还可以尽管如此，很多事情都很可爱。没有ORM-商业或手工编码。该SQL已编译为您可以查看的代码（它已生成，因此已针对速度进行了优化，以提高可读性，并且变量名可以是诸如“ T32”之类的东西，但是如果需要的话，它仍然是可读的），甚至是逐步操作或断点操作。编写SQL游标的成本非常低。您实际上可以编写面向对象的代码。它是经过解释的，因此更容易快速开发。如果您想提高速度，可以关闭事务并转到“ No SQL”。

我也发现它非常易于管理。在我的大多数经验中，没有DBA之类的东西-您只是不需要DBA。