Re: SQL vs. traditional I/O? (my two cents)

Hi, all:

Here is my "take" on this whole debate:

SQL (structured query language) is based on the idea of a "set at a time" 
versus the "record at a time" paradigm of most 3GLs and DBMSs that preceded it. 
 It was also developed around the time when 4GLs were "in vogue" ... (4GLs 
espouse the principle of "State what results you want, not how to do it.")

So, if the problem you need to solve is, for example, to "update every record 
where the salary is > 10,000" then this is probably well-suited to SQL.

If the problem is more like, find the single record for Joe, and decrease his 
salary by 10,000" then traditional 3GL I/O will probably work just as well, if 
not better than, an SQL-based solution.

Part of the "big idea" of going to "relational" databases was to design 
"normalized" tables and to remove as much of the database "navigation" logic as 
possible from the actual applications programs. (If you think of most older 
DBMS systems, such as TOTAL, IMS, IDMS, etc., you had to "hard-code" all sorts 
of logic into each application to "navigate" through the "hierarchy" or 
"network"... remember, before "relational, there were two basic database 
designs, hierarchical, and network.

So, if your database design is based on an older "flat-file" design, perhaps 
migrated from S/36, with some indexes (logical files), then you might be better 
off to stick with the traditional 3GL style I/O, versus trying to use possibly 
convoluted SQL statements to achieve the same results.

To summarize, to get the best results with SQL, you should probably have a 
"good" relational database design, to begin with. ("Good design" means whatever 
you like; start with Entity-Relationship Diagrams, 3rd normal form, etc....)

That's my two cent's worth ... 

Mark S. Waterbury