× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.




A colleague of mine proposed to create a service program for each new
table, implementing the CRUD functionalities in SQL. We would be using the
functions from the service program to access the files instead of native
RPG I/O.


For CRUD operations, have you considered wrapping RPG I/O in service
program procedures?


The arguments are that IBM is focusing its improvements on SQL, and
leaving native I/O behind.


I'd like pass along a quote from Jon Paris:

"I'm not a fan of "SQL is the answer... Now, what what the question?"

SQL was designed for set-based functionality while RPG I/O was designed for
record-level access. Both are valid use cases.


Also this would separate data access from business logic and in time
create a database layer.


Good architectural point.

An other solid argument is that we would limit the need for creating
indexes, and could construct the appropriate access paths when performance
is evaluated.


CRUD operations without indexes? No, I hope the fallacy of that is obvious.

However, I have some doubts for this approach.


If you have doubts about SQL being the answer to CRUD operations, you're
not alone.

I fear that it would discourage developers to create programs starting from
a joined SQL statements (program join), instead encourage sequential read
operations from multiple files (program join).


When you need to join files, I'd recommend SQL Views and Join Logicals over
program joined operations.

I feel this is where most of the performance gains can be found.
Additionally, I've always thought that native I/O is more performant in
retrieving a small amount of records from a file...


I've done some benchmark testing where RPG op codes performed 100% - 600%
more efficiently than SQL equivalents. Testing a foreign-key RI constraint
using SETLL for example may perform 600% more efficiently than an SQL
SELECT.

I thought the service programs could lead to deterioration of performance.


Actually, I would recommend wrapping CRUD operations in I/O service
programs for the following reasons:

1. Avoids the problem of "F" specs multiplying like rabbits and having to
recompile many modules when file layouts occur.
2. Avoids multiple open-data paths when multiple programs need access to
the same files in the same job.
3. Facilitates a standard interface for I/O error handling (appropriate
error messages).
4. Facilitates the principles of loose coupling and high cohesion between
DB I/O modules and application modules.
5. Facilitates code maintenance by appropriately scoping I/O service
programs.

In summary, the idea of encapsulating CRUD operations into service programs
is good, but the idea of SQL being the answer to all I/O, is bad.

You asked about CRUD operations. Requirements for dealing with "result
sets" is a different matter, and something which SQL excels at.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.