The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

ISAM vs SQL RDBMS

A CRM product we're looking at uses raw ISAM files as its backend store. The vendor has an SQL database version, but recommends against that choice.

If it were 1975 I would choose to use ISAM. But really, is there a reason today (besides price) to not build an enterprise product on top of SQL ?
I used VSAM once, long ago
Thursday, April 20, 2006
 
 
Does the vendor provide reasons for their recommendation?
David Aldridge Send private email
Thursday, April 20, 2006
 
 
Building new?  No reason not to use SQL, even if only to win the sales of people who absolutely want to run it on their RDBMS (SQL Server, Oracle, DB2).

If you have to worry about all the enterprise-level stuff (audit, security, backup, redundancy, disaster recovery, etc.) - customers will want it on a platform they understand and support already.
Cade Roux Send private email
Thursday, April 20, 2006
 
 
>Does the vendor provide reasons for their recommendation?

Not directly. Other than slightly higher harware spces. They also claim that the isam version is rock solid under high load so it must be as good as the sql version.
  They describe how only a few of their customers have chosen the sql option.
  The sql option is more expensive, maybe they are afraid of losing the sale.
I used VSAM once, long ago
Thursday, April 20, 2006
 
 
I would read their use of ISAM and recommendation against SQL Server to mean "we don't employ anyone who really knows anything about relational databases so the SQL Server version of our product is not that great".

Maybe you could try get a test copy of both versions and see if there's a difference in performance/bug count/etc.
CK Send private email
Thursday, April 20, 2006
 
 
I worked at a place where the product (the core written in the 70's) used ISAM rather than SQL. We had Oracle, SQL and DB2 versions but all they did was store the data in exactly the same format as the flat files and read them in pretty much the same way (in fact I think there was some translation where the tables were read out into a file and dealt with in exactly the same way).

The reason for this was replacing it would have meant rewritting what was a totally stable application.
Andy.. Send private email
Friday, April 21, 2006
 
 
>>  The sql option is more expensive, maybe they are afraid of losing the sale.

Or they're buying the SQL Server license for the installation.

I think Andy..  may have it-they have a solid product and are layering sql on top of their proven stuff.  In that case, recommending the ISAM version a) removes a potential performance limiter and b) removes an added cost.
a former big-fiver Send private email
Friday, April 21, 2006
 
 
Nothing to add here, just the statement that I *hate* things that are essentially ISAM within an SQL (relational) database. It's like they just put the SQL wrapper around it to say "Lookie here ... We're ESS-QUEUE-ELL compatible" when really they're still doing ISAM within the SQL server.

What's the point? I see this all the time. I hate it.
Sgt.Sausage
Friday, April 21, 2006
 
 
A key indexed file will blow a database away any day on sorts and the like.

Friday, April 21, 2006
 
 
What relationship does the MySQL MyISAM storage engine have with "ISAM" in this context? any help?
Shane Send private email
Monday, April 24, 2006
 
 
>>  A key indexed file will blow a database away any day on sorts and the like.


Details?
David Aldridge Send private email
Monday, April 24, 2006
 
 
Shane: MySQL has an option to use "real" ISAM files. Why bother with MyISAM when you can have the real thing and be compatible?

Sgt.Sausage: the point is people want SQL. A better question is, WHY do they want SQL?

http://phpbb.blcss.com/viewtopic.php?t=33
Rowland
Tuesday, April 25, 2006
 
 
>> http://phpbb.blcss.com/viewtopic.php?t=33

That's some pretty dumb reasoning. A good application doesn't build a new string everytime it needs to query the database, it just binds in the values it needs for the predicate. That's also the bullet-proof approach to avoiding SQL injection attacks.

So what the author was saying was that SQL makes no sense when it is badly used. Duh.
David Aldridge Send private email
Tuesday, April 25, 2006
 
 
"A good application doesn't build a new string everytime it needs to query the database, it just binds in the values it needs for the predicate."

"Binds in?" What does that mean, exactly? And how does it differ from building a string? I'm not sure what your point is here.

Are you talking about DBI::bind_col? That's awfully language dependent, isn't it? And what about inserts or updates? That's where the worst security concerns are. A malicious user can really mess us up with those.
Rowland
Tuesday, April 25, 2006
 
 
Binds as in bind variables -- thus avoiding a reparsing of the SQL every time it is submitted to the database. Selects, inserts, updates, deletes, they can all be bound, and if oyu're working with (eg) Oracle and you're not doing this then you're not building a scalable application.

Everything is language dependent, and in when you're working with databases an agnostic approach sucks. Life's hard.
David Aldridge Send private email
Wednesday, April 26, 2006
 
 
"Selects, inserts, updates, deletes, they can all be bound"

Okay, show us an example. Language: PHP. Database: MySQL. Command: INSERT. What would the code look like to bind it?

For extra credit, as above but substitute Perl for PHP.

For extra extra credit substitute MS SQL for MySQL.
Rowland
Wednesday, April 26, 2006
 
 
P.S.

Just to make sure there's no misunderstandings, the code should use only standard features and libraries likely to be found on a typical installation or hosting provider. No add-ons such as ADOdb unless you include that as PART OF the sample code.

And no SQL features that aren't commonly implemented or which work entirely differently on different versions. So no stored procedures!

If you have to add something to SQL to make SQL defensible then you haven't defended the honor of SQL. You've merely obscured the issue. It's SQL as SQL that's the issue here.
Rowland
Wednesday, April 26, 2006
 
 
>> Just to make sure there's no misunderstandings, the code should use only standard features and libraries likely to be found on a typical installation or hosting provider. No add-ons such as ADOdb unless you include that as PART OF the sample code.

The only thing that you're making sure of is that your application will run poorly and be unscalable. Your's is a 100% commercial-convenience-of-the-vendor argument with no technical merits ... you ought to add that as a disclaimer to every statement you make of this type. "Not based on sound technical knowledge".

>> And no SQL features that aren't commonly implemented or which work entirely differently on different versions. So no stored procedures!

Do you also assume that all operating systems use the same memory management? File system? Of course not. IMHO the major advantage of stored procedures is that it is more likely to keep database development in the hands of those who understand it, and out of the hands of those who don't understand databases and who aren't willing to put in the time and effort to learn how to use them properly.

>> If you have to add something to SQL to make SQL defensible then you haven't defended the honor of SQL. You've merely obscured the issue. It's SQL as SQL that's the issue here.

The article was based on misusing SQL in order to attack it, hence I challenged its validity. SQL is designed to be human-readable for the same reason that C, Java et al are human-readable, and I don't see anyone complaining about them or rushing to use assembler.

The fact is (with regard to Oracle in particular) that if you are building strings of SQL in an application and not using bind variables then you are implicitly causing the very problems that the article author writes of -- requiring reparsing of every statement and susceptibility to SQL injection. It's the equivalent of a driver complaining that manual transmissions suck because they have to be rebuilt all the time, when they are causing the problem by failing to use the clutch!
David Aldridge Send private email
Wednesday, April 26, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz