The way to the future is to forget ISAM and use higher levels of
abstraction to access databases. SQL is only the next step, then there are
data access procedures/functions, next level are ORM (object relational
mapping) frameworks.
I find that transforming the ISAM acronym into a generic term for any
record-level access in any database to be distracting because it was a term
that IBM came up with, for one of its mainframe file systems, which was
later replaced by VSAM, which required a data conversion and program
changes. ISAM was viewed as outdated, and that seems to be the connotation
with which you raise the term.
Moreover IBM has never said that ISAM was an underlying file system for the
IBM i platform, nor any of its predecessors. The only references in the IBM
i Knowledge Center are ones which contrast ISAM with DB2, as opposed to
comparisons. There is no mention of DB2 using ISAM under the covers, for
example.
Indexing layouts and algorithms have evolved since the days of ISAM. IBM i
supports a couple index types, namely Binary Radix and Encoded Vector.
In regards to your position about using higher levels of abstraction to
access databases, I agree there's a value in SQL which applies to certain
use cases such as selecting, joining, and working with result sets. But
there are also many valid and compelling use-cases for record-level access,
which should be acknowledged. SQL and RLA compliment one another rather
than compete.
In regards to ORMs, they are an example of OO taken to an extreme. They add
a ton of overhead. The facilitate the movement of business rules into
language environments which are not well suited for that kind of
processing, they create a sense that a DBMS is merely a "persistence"
layer. I think ORMs cause more harm than they do good.
midrange.com
