当应用程序设计需要过程代码和大量数据库时，许多开发人员似乎要么害怕，要么有点不知所措。在大多数情况下，“数据库”是指带有 SQL 接口的 RDBMS。
然而在我看来，用于解决两种范式之间“阻抗不匹配”的许多技术将更适合 ISAM（索引顺序访问方法）工具集，您可以（必须）指定表、索引、行- 导航等公开 - 例如，完全符合 ActiveRecord 模型规定的行为。
在早期的 PC 时代，dBASE 及其后代是主要的 dbms 平台，它是增强的 ISAM。Foxpro 非常成功地将这一血统延续到今天。MySQL 和 Informix 是至少最初构建在 ISAM 实现之上的两个 RDBMS，因此这种方法至少应该具有相同的性能。我感觉许多对 SQL 不满意的开发人员至少在不知不觉中渴望 ISAM 方法能够复兴，并且可以更容易地将数据库视为一组高效的可链接超阵列。在我看来，这可能是一个非常好的主意。
例如，您是否尝试过 ORM 到 ISAM 的实现？有多成功？如果没有，您认为值得一试吗？该模型是否有明确的工具集？
也许猪拉丁是你想要的？根据这篇文章 http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=693D79B5EFDC0452E1C9A87D1C495D4C?doi=10.1.1.124.5496&rep=rep1&type=pdf：
“此外，许多分析这些数据的人都是根深蒂固的过程式程序员，他们发现声明式的 SQL 风格是不自然的。更加过程化的 map-reduce 编程模型的成功，以及它在商品硬件上的相关可扩展实现—— ware, 是上述的证据。但是，map-reduce 范式太低级和死板，导致大量自定义用户代码难以维护和重用。我们描述了一种新的语言，称为 Pig Latin我们的设计是为了在 SQL 的声明式风格和 map-reduce 的低级程序风格之间找到一个最佳位置。”
与成熟的 SQL DBMS 相比，ISAM 在某些时间和地点以更少的成本和开销提供应用程序所需的服务。ISAM 机制的一个缺点是不一定有系统目录来描述数据。另一个是通常很少有用户友好的工具来获取数据。这些都是 RDBMS 提供相当大优势的地方。最好的 ISAM（或类似）系统提供事务支持——有时甚至是 XA 事务。
当您需要进行复杂的连接和计算（例如聚合）时，DBMS 所做的工作提供了巨大的好处。如果您只需要访问记录，那么 ISAM 可能会有所帮助。
使用基于 ISAM 的系统比使用 DBMS 更难实施安全性。此外，您需要担心崩溃时文件的完整性。大多数 DBMS 使用双进程架构（DBMS 客户端与 DBMS 服务器位于一个单独的进程中），这在客户端崩溃（或客户端 PC 被关闭）时提供了弹性。您还必须担心备份和恢复 - 一个称职的 DBMS 具有适当的系统，可以在数据库使用时提供数据库的一致备份；目前尚不清楚 ISAM 系统能否提供这种级别的完整性。
总的来说，给定一个合适的 ISAM 机制，在 ORM 系统中使用 ISAM 机制而不是完整的 RDBMS 至少有时，也许经常是有优势的。
我在 1990 年代实现了一个 ORM-to-isam 库，它作为共享软件获得了一些（非常）适度的成功。我在很大程度上同意你所说的 ISAM 的优点，如果你只寻求灵活性和速度，我认为在构建 ORM 层或产品时使用 ISAM 更好。
但是，您所承担的风险是您将失去目前市场上广泛的 SQL 相关产品的好处。特别是，报告工具已经发展到与最流行的 SQL 包更紧密地集成。虽然 1990 年代的 ISAM 产品供应商提供了 ODBC 驱动程序以与 Crystal Reports 等产品集成，但即使在那时，市场似乎也在逐渐远离 ISAM，如果我继续使用该技术，我将面临被淘汰的风险。因此，我切换到 SQL。
一个警告：自从我在 ISAM 沙盒中玩游戏以来已经快十年了，所以我不能声称掌握最新的 ISAM 工具及其解决此问题的方法。但是，除非我确信我不会在没有报告工具支持的情况下陷入困境，否则我不会采用基于 ISAM 的 ORM，无论其优点如何。这甚至不包括可用于基于 SQL 的开发的其他工具！
我完成了 dBase、Clipper 和 FoxPro 的分享。但是我相信 SQL 提供的关系模型更加强大和有用，像 Oracle 和 SQL Server 这样的产品应该在市场上取得成功。
我总是很惊讶为什么人们如此重视为大约 80-90% 的案例创建映射层并编写 10-20% 的自定义 SQL 来处理复杂的查询（主要是报告）和批量数据移动。考虑到对休眠、活跃记录等的仇恨程度，我必须通过采用 DAL/DAO 模型来做一些非常好的或非常愚蠢的事情 - 参见之前的越南讨论。
多值数据库有人吗？（又名 Pick）认为没有标签的 XML。它们比 RDBMS 早了至少十年，如果你知道去哪里看，它们仍然很强大。
如果您确切地知道要对数据执行什么操作以及如何执行此操作，请选择 ISAM。您会很高兴，因为您将构建索引来满足您的确切需求。预先知道，如果您的需求发生变化，您将需要更改索引。数据访问速度将非常快。
如果您不确定数据将用于什么用途，或者您知道您的数据需求会随着时间的推移发生很大变化，请选择 SQL。您将拥有临时查询、快速报告周转、数据挖掘等的灵活性。
多年来，这两种类型的数据库都已经成熟。两者都可以拥有具有实时备份、事务、安全性、元数据等的强大服务器。
老问题，但有趣的讨论。ISAM的概念很重要，我们在当今的 RDBMS 中提供的附加功能（如所讨论的，即备份、一致性、安全性、元数据）为我们提供了显着的好处。
NoSQL 热潮（是的，我说过......热潮）并不意味着我们不能在 RDBMS 中对类似 ISAM 的访问进行建模。你肯定我会尽可能多地将逻辑推向数据库，但有时像“传统”数据网格化/多维数据插值，我会通过我自己的逻辑遍历所有必要的记录指数。