+1 for all responses. I would go so far as saying one should (ymmv) never access tables directly in applications. A view should be the closest one gets to the "bare metal" of the database.
Here's another reason:
Take any embedded SQL statement in a program - let's say it joins 2 or more other data objects, does some criteria, etc. Note that this query cannot be shared with another process.
It is private and "rude" actually :-) What's so special about this query to where another process can't use it?
Move the query to a view, describe it appropriately, and now any other application can take advantage of the query.
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Thomas Garvey
Sent: Friday, August 24, 2018 14:11
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: SQL Views worth it?
I'm developing a new application and trying to have the DB do as much of
the work as possible.
So, I'm incorporating SQL Views but finding the throughput underwhelming.
Granted that some of the views are based on other views (in keeping with
the attempt to have the DB do some work for me)
but it appears that every time a view is queried the views are rebuilt
by the OS.
I read somewhere that Views can be considered somewhat like logical
files, but at least logicals
can be set to have immediate updates as underlying physicals change.
Views have no such attribute settings.
So, what's considered best practices for SQL Views?
Should I just rewrite these things as logicals?
This mailing list archive is Copyright 1997-2020 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