logo标签列表

选择ISAM而不是SQL

sqlormisam
6
许多开发人员在应用程序设计需要过程性代码和大量数据库时似乎有些害怕或不知所措。在大多数情况下，“数据库”意味着具有SQL接口的RDBMS。
然而，对我来说，许多解决两种范例之间的“阻抗失配”的技术更适合使用ISAM（索引顺序访问方法）工具集，其中您可以（必须）明确指定表、索引、行导航等 - 正是ActiveRecord模型所规定的行为。
在早期的PC时代，dBASE及其后代是主要的dbms平台，而且它是一个增强的ISAM。 Foxpro通过今天成功地延续了这一血统。 MySQL和Informix是两个最初至少基于ISAM实现构建的RDBMS，因此此方法应该至少同样有效。我感觉许多不满意SQL的开发人员至少是下意识地渴望ISAM方法得到恢复，并且可以更轻松地将数据库视为一组高效的可链接超级数组。对我来说，这可能是一个非常好的想法。
您是否尝试过ORM-to-ISAM实现？取得了多少成功？如果没有，您认为值得一试吗？是否有专门针对此模型的工具集？
7个回答
3
也许你需要的是Pig Latin？根据这篇文章http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=693D79B5EFDC0452E1C9A87D1C495D4C?doi=10.1.1.124.5496&rep=rep1&type=pdf： “此外，许多分析此数据的人都是执着于程序编程的人，他们认为声明式的SQL风格不自然。更加过程化的map-reduce编程模型及其在商品硬件上的可伸缩实现的成功证明了这一点。然而，map-reduce范例过于低级且刻板，导致大量定制用户代码难以维护和重用。我们描述了一种名为Pig Latin的新语言，设计它来适应SQL的声明性风格和map-reduce的低级过程式风格之间的甜蜜点。”
2
在某些情况下，ISAM机制提供了应用所需的服务，并且相比于完整的SQL DBMS，其成本和开销更少。 ISAM机制的一个缺点是并不一定有系统目录来描述数据; 还有一个问题是通常很少有用户友好型工具来获取数据。这些都是关系数据库管理系统（RDBMS）提供显着优势的地方。最好的ISAM（或类似）系统提供事务支持，甚至有时提供XA事务。
在需要进行复杂连接和计算（例如聚合）时，DBMS提供的工作会带来巨大的好处。如果只需要访问记录，则使用ISAM可能会有益。
安全性倾向于在基于ISAM的系统中较难执行，而非DBMS。此外，在发生崩溃的情况下，您需要担心文件的完整性。大多数DBMS使用两个进程体系结构（DBMS客户端与DBMS服务器分别在不同进程中），这可以在客户端崩溃（或客户端PC关闭）时提供弹性。您还必须担心备份和还原 - 能够提供数据库一致备份的能力是DBMS的一个重要功能； ISAM系统是否提供该级别的完整性则不确定。
总的来说，如果有合适的ISAM机制，使用ISAM机制在ORM系统中，与使用完整的RDBMS相比，至少有时候可能会带来优势。
但是这些功能在过去已经被纳入了ISAM包中。dBASE有目录，我认为FoxPro有事务处理。一个服务器守护程序会非常简单（并且可能是一个好主意）。但我主要考虑的是客户端和数据之间的逻辑接口。 - dkretz
1

在上世纪90年代，我实现了一个ORM-to-isam库，作为共享软件获得了一些（非常）适度的成功。我基本上同意你所说的ISAM的优点，如果你只寻求灵活性和速度，构建ORM层或产品时最好使用ISAM。

然而，你要承担的风险是，你将失去市场上各种SQL相关产品的好处。特别是，报表工具已经发展到与最流行的SQL包紧密集成的程度。虽然上世纪90年代的ISAM产品供应商提供了ODBC驱动程序，以与Crystal Reports等产品集成，但当时似乎市场趋势正在远离ISAM，如果我继续使用那种技术，我将冒着过时的风险。因此，我转向了SQL。

一个警告：自从我玩ISAM沙盒已经快十年了，所以我不能声称我掌握了最新的ISAM工具及其解决这个问题的方案。然而，除非我确信不会被困在没有报表工具支持的境地，否则我不会采用基于ISAM的ORM，无论它有多少优点。这甚至还没有涉及到基于SQL的开发可用的其他工具！

如果没有使用SQL，Foxpro会有多大的偏差？ - dkretz
我不确定我理解了...你是否有可用于Foxpro数据的ORM接口？ - Mark Brittingham
不知道，但它拥有所有的工具，报告编写器等。 - dkretz
1

我曾经使用过dBase、Clipper和FoxPro。然而，我认为SQL提供的关系模型无限更强大和有用，像Oracle和SQL Server这样的产品在市场上获得了成功。

我总是很惊讶为什么人们会对创建映射层和编写10-20%的自定义SQL来处理复杂查询（主要是报告）和批量数据移动的80-90%的情况如此重视。鉴于对hibernate、active record等的憎恨程度（参见早期的越南讨论），采用DAL/DAO模型可能是我做得非常好或非常愚蠢的事情之一。

我同意，但我们必须面对一个事实，即重要的交易正在进行，无论问题是否存在，人们都在不断想出新的方法使事情变得更加复杂 - 超越SQL。无论如何，关于LINQ / ORM，它们并不是简化工具 - 只是更多的开销。 - dkretz
在处理时间上还是在学习技术上增加更多的开销？或者可能是在寻找使技术适应您特定问题的方法上增加开销？我对LINQ和Hibernate都不是很感兴趣-它们的限制很快就会显现出来。 - Otávio Décio
主要是学习 - 我同意LINQ/Hibernate/ORM似乎增加了复杂性，而没有在其他方面进行足够的简化，使其值得去做。 - dkretz
1
多重值数据库（也称为Pick）有人使用吗？想象一下没有标签的XML。它们比关系型数据库至少早十年，并且如果您知道在哪里寻找，它们仍然非常强大。
数组？你想要数组？没问题！ - dkretz
1
如果您确切地知道您想要使用数据做什么以及如何做到这一点，请选择ISAM。您会感到高兴，因为您已经将索引结构化以满足您的确切需求。请事先知道，如果您的需求发生变化，您将需要更改索引。数据访问将非常快速。
如果您不确定数据将用于什么用途，或者您知道您的数据需求随时间而变化很大，请选择SQL。您将具有自由查询、快速报告周转、数据挖掘等灵活性。
这两种类型的数据库在多年的发展中都已成熟。它们都可以拥有具有实时备份、事务、安全性、元数据等功能的强大服务器。
0

虽然这是一个老问题，但讨论很有趣。ISAM的概念很重要，今天的RDBMS提供的附加功能（如备份、一致性、安全性、元数据等）为我们带来了显著的好处。

随着NoSQL热潮的出现（是的，我说了...热潮），这并不意味着我们不能在RDBMS中建模类似于ISAM的访问方式。我会尽可能地将逻辑推到数据库中，但在传统的数据网格/多维数据插值等时候，我会通过自己的逻辑索引遍历所有必要的记录。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接