当应用程序设计需要过程代码和实质数据库时,许多开发人员似乎要么被吓倒,要么有点不知所措.在大多数情况下,"数据库"表示带有SQL接口的RDBMS.
然而在我看来,解决两种范式之间"阻抗不匹配"的许多技术将更适合于ISAM(索引顺序访问方法)工具集,您可以(必须)指定表,索引,行-naviagation等明显 - 正好是ActiveRecord模型规定的行为.
在PC早期,dBASE及其后代是主要的dbms平台,它是一种增强的ISAM.Foxpro在今天成功延续了这一血统.MySQL和Informix是两个至少最初构建在ISAM实现之上的RDBMS,因此这种方法应至少具有同等性能.我感觉许多对SQL不满意的开发人员至少在无意识中渴望恢复ISAM方法,并且数据库可以更容易被视为一组高效的可链接超阵列.在我看来,这可能是一个非常好的主意.
你有没有试过一个ORM-to-ISAM实现？怎么成功？如果没有,您认为值得一试吗？该模型是否有明确的工具集？
我在 20 世纪 90 年代实现了一个 ORM 到 isam 库，作为共享软件取得了一些（非常）有限的成功。我非常同意您所说的 ISAM 优点，并且我认为如果您只追求灵活性和速度，那么在构建 ORM 层或产品时最好使用 ISAM。
然而，您所承担的风险是您将失去目前市场上各种 SQL 相关产品的优势。特别是，报告工具已经发展到与最流行的 SQL 包更加紧密地集成。虽然 20 世纪 90 年代的 ISAM 产品供应商提供了 ODBC 驱动程序来与 Crystal Reports 等产品集成，但即使在那时，市场似乎也正在远离 ISAM，如果我继续使用该技术，我将面临被淘汰的风险。因此，我转向了 SQL。
需要注意的是：自从我在 ISAM 沙箱中玩游戏以来已经有近十年了，所以我不能声称自己掌握了最新的 ISAM 工具及其对这个问题的解决方案。然而，除非我确信在没有报告工具支持的情况下我不会陷入困境，否则我不会采用基于 ISAM 的 ORM，无论其优点如何。这甚至不包括可用于基于 SQL 的开发的其他工具！