Choosing ISAM, not SQL

Question

Many developers seem to be either intimidated or a bit overwhelmed when the application design requires both procedural code and a substantial database. In most cases, “database” means a DBMS with an SQL interface.

However, it seems to me that many of the methods for solving the "impedance mismatch" between the two paradigms will be much better suited to the ISAM tool kit (indexed sequential access method), where you can (should) specify tables, indexes, row-naviagation, etc. - exactly the behavior prescribed by the ActiveRecord model, for example.

In the early days of the PC, dBASE and its offspring were the dominant dbms platforms, and it was an improved ISAM. Foxpro continues this line quite successfully until today. MySQL and Informix are two RDBMSs that, at least, were originally built on top of ISAM implementations, so this approach should be at least equally effective. I have the feeling that many developers who are unhappy with SQL, at least unconsciously, want the ISAM approach to be restored, and the database could be more easily viewed as a set of massive effective hyperlinks. It seems to me that this can be a really good idea.

Have you ever tried, say, an ORM-ISAM implementation? How successful? If not, do you think it's worth a try? Are there any tools for this model explicitly?

Answer 1

I implemented the ORM-to-isam library back in the 1990s, which enjoyed some (very) modest success as shareware. I basically agree that you are talking about the virtues of ISAM, and I believe that it is better to use ISAM when creating an ORM layer or product if you are looking only for flexibility and speed.

However, the risk that you take is that you will lose the benefits of the wide range of SQL-related products currently on the market. In particular, reporting tools have become increasingly tightly integrated with the most popular SQL packages. While ISAM vendors in the 1990s provided ODBC drivers with integration with products such as Crystal Reports, even then it seemed that the market was diverging from ISAM and that I would risk obsolescence if I continued to use this technology. So I switched to SQL.

One caveat: it has been almost ten years since I played in the ISAM sandbox, so I cannot claim the latest ISAM tools and their solutions to this problem. However, if I was not convinced that I would not fall into the trap without the support of reporting tools, I would not accept ISAM-based ORM, regardless of its merits. And that doesn't even cover the other tools available for SQL development!

Answer 2

Perhaps Pig Latin is what you want? According to this article http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=693D79B5EFDC0452E1C9A87D1C495D4C?doi=10.1.1.124.5496&rep=rep1&type=pdf :

“In addition, many of those who lyze this data are rooted in procedural programmers who find declarative, SQL style unnatural. The success of a more procedural programming model and its associated scalable implementations in the product market, testifies to this. However, the reduction paradigm The cards are too low-level and hard, and leads to a large user code that is difficult to maintain and reuse. We describe a new language called Pig Latin, which we designed to make sweet a spot between the declarative style of SQL, as well as the low, procedural style of map reduction.

Answer 3

Of course, there are times and places where ISAM provides the services needed for the application, with less cost and overhead than a full-blown SQL DBMS. One of the disadvantages of the ISAM mechanism is the lack of a system catalog for describing data; the other is that, as a rule, several user-friendly tools are available for accessing data. These are both places where the DBMS provides significant benefits. The best ISAM (or similar) systems provide transaction support - sometimes even XA transactions.

If you need to perform complex joins and calculations (for example, aggregates), the work performed by the DBMS provides huge advantages. Where all you need is access to records, then ISAM can be useful.

Security, as a rule, is more difficult to apply with an ISAM-based system than with a DBMS. In addition, you need to worry about file integrity in the event of a failure. Most DBMSs use a dual-processor architecture (DBMS client in a separate process from the DBMS server), which ensures stability in the face of a client failure (or shutdown of the client PC). You also need to worry about backing up and restoring - a competent DBMS has systems to provide a consistent database backup when the database is in use; it is not clear that ISAM systems will provide this level of integrity.

In general, given the appropriate ISAM mechanism, at least sometimes, perhaps, the advantages of using the ISAM mechanism in an ORM system instead of a full RDBMS.

Answer 4

I made my share in dBase, Clipper and FoxPro. However, I believe that the relational model provided by SQL is infinitely more powerful and useful, and products such as Oracle and SQL Server deserve market success.

I always wonder why people do such a great job of creating a mapping layer for 80-90% of cases and writing 10-20% of custom SQL to handle complex queries (mostly reports) and batch moving data. I have to do something really good or something really stupid by adopting the DAL / DAO model, given the level of hate versus sleep mode, active recording, etc. - Discussion of the Vietnamese discussion earlier.

Answer 5

A multi-valued database? (aka Pick) Think XML without tags. They precede RDBMS for at least a decade, and are still strong if you know where to look.

Answer 6

If you know exactly what you want to do with your data and how you want to do it, select ISAM. You will be happy because you will structure your indexes to meet your specific needs. Know in advance that if your needs change, you will want to change your indexing. Access to data will grow rapidly.

If you are not sure what will use the data, or you know that your data will change greatly over time, select SQL. You will have the flexibility of special queries, quick turn of reports, data mining, etc.

Both types of databases have matured over the years. Both can have reliable servers with backup, transactions, security, metadata, etc.

Answer 7

An old question, but an interesting discussion. ISAM concepts are important, the additional features that we provided today with RDBMS (as discussed, for example, backups, consistency, security, metadata) offer us significant advantages.

With NoSQL hobby (yes, I said it ... hobby), this does not mean that we cannot model ISAM access in RDBMS. You will be sure that I am going to drop as much logic in the database as possible, but there are moments like “traditional” data binding / multidimensional data interpolation, where I will go through all the necessary records through my own logical index.