On 9/15/2016 1:33 PM, Joni Vanderheijden wrote:
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.
I have a somewhat radical reply. Forget about SQL for the time being.
Imagine writing the CRUD functions using native I/O, but don't focus on
CHAIN, SETLL, etc. Instead, turn your thoughts to the interface. If
you need a list of products a customer bought, how would you return that
list to the caller? What about errors - they can and will pop up.
Decimal data errors, record locks, RI violations, etc. How will you
feed those errors back to the caller?
Consider the I/O calls as APIs, or better yet, as built in functions.
Imagine you could write
structure = getProductListForCustomer(customerID);
What would 'structure' look like? An array? A linked list? (Mihael
Schmidt has already done that work
http://rpgnextgen.com/ - look on the
right hand side). Maybe you'll use a result set [exec sql associate
result set locators (:resultSet) with procedure getSomeViewColumns;]
What you need to do is to analyse your application and look for places
where you can write code which will isolate the I/O into modular,
reusable functions. Functions which are closely aligned with the
business problem, not to the database. Which is why I very much agree
that these I/O abstractions should be using VIEWs whenever possible, and
not TABLEs.
TABLEs are intended to be normalised for efficient use by the database
engine, and thus one row in a table won't represent a complete 'business
object' like 'customer ship to contact information'.
VIEWs are intended for efficient use by the programmers :-) One row in
a VIEW can and should represent a complete business object.
midrange.com
