选择ISAM而不是SQL

Question

当应用程序设计既需要过程代码又需要大量数据库时，许多开发人员似乎要么感到害怕，要么有点不知所措。在大多数情况下，“数据库”指的是具有SQL接口的RDBMS。

然而，在我看来，许多用于解决这两种范例之间的“阻抗不匹配”的技术更适合于ISAM (索引顺序访问方法)工具集，在该工具集中，您可以(必须)公开地指定表、索引、行导航等--例如，完全符合ActiveRecord模型所规定的行为。

在早期的PC时代，dBASE和它的后代是占主导地位的数据库管理系统平台，它是一个增强的ISAM。Foxpro将这一血统成功地延续到了今天。MySQL和Informix是两个RDBMS，至少最初是在ISAM实现的基础上构建的，因此这种方法至少应该具有同等的性能。我有一种感觉，许多对SQL不满意的开发人员至少在不知不觉中渴望ISAM方法的复兴，并且数据库可以更容易地被视为一组高效的、可链接的超数组。在我看来，这可能是一个非常好的想法。

你有没有尝试过，比如说，ORM到ISAM的实现？有多成功？如果不是，你觉得值得一试吗？是否有针对此模型的显式工具集？

Answer 1

我在20世纪90年代实现了一个ORM-to-isam库，它作为共享软件取得了一些(非常)的成功。我在很大程度上同意您所说的ISAM的优点，如果您只想获得灵活性和速度，我认为在构建ORM层或产品时使用ISAM会更好。

但是，您所承担的风险是，您将失去目前市场上广泛的SQL相关产品的好处。特别是，报告工具已经发展到与最流行的SQL包更加紧密地集成在一起。虽然ISAM产品供应商在20世纪90年代提供了ODBC驱动程序来与Crystal Reports等产品集成，但即使在那时，市场似乎也在逐渐远离ISAM，如果我继续使用这项技术，我将面临过时的风险。因此，我转而使用SQL。

需要注意的是:我使用ISAM沙箱已经快十年了，所以我不能声称自己熟悉最新的ISAM工具及其对此问题的解决方案。然而，除非我确信没有报告工具支持我不会陷入困境，否则我不会采用基于ISAM的ORM，不管它有什么优点。这还不包括其他可用于基于SQL的开发的工具！

Answer 2

也许小猪拉丁就是你想要的？根据这篇文章http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=693D79B5EFDC0452E1C9A87D1C495D4C?doi=10.1.1.124.5496&rep=rep1&type=pdf：

此外，许多分析这些数据的人都是根深蒂固的过程式程序员，他们发现声明式的

风格是不自然的。更加程序化的map-reduce编程模型的成功，以及它在商用硬件上的相关可伸缩实现，就是上述情况的证据。然而，map-reduce范例太低级和僵化，导致大量自定义用户代码难以维护和重用。我们描述了一种名为Pig拉丁语的新语言，它是我们设计的一种介于SQL的声明性风格和低级的、过程化的map-reduce风格之间的最佳选择。“

Answer 3

在某些时间和地点，ISAM以比成熟的SQL DBMS更少的成本和开销提供应用程序所需的服务。ISAM机制的一个缺点是，不一定有一个系统目录来描述数据；另一个缺点是，通常很少有用户友好的工具来获取数据。在这两个方面，RDBMS提供了相当大的优势。最好的ISAM (或类似的)系统提供事务支持--有时甚至是XA事务。

在需要进行复杂的连接和计算(例如聚合)的地方，由DBMS完成的工作提供了巨大的好处。如果您所需要的只是访问记录，那么ISAM可能是有益的。

使用基于ISAM的系统往往比使用DBMS更难实施安全性。此外，您还需要担心在崩溃的情况下文件的完整性。大多数DBMS使用双进程体系结构(DBMS客户端在独立于DBMS服务器的进程中)，这在客户端崩溃(或客户端PC被关闭)面前提供了弹性。您还必须考虑备份和恢复问题--一个合格的DBMS具有相应的系统，用于在数据库正在使用时提供一致的数据库备份；目前尚不清楚ISAM系统是否会提供这种级别的完整性。

总体而言，在给定适当的ISAM机制的情况下，在ORM系统中使用ISAM机制而不是完整的RDBMS至少有时会有好处。