If you code and execute your SQL statement that is saved in the view
directly, how is the performance?
Same as using the view, better or worse?

There are only 2 things we can do to affect the query optimizer decisions:
1. Providing the right indexes
2. The way in which we code an SQL statement.

May be it help if you show the SELECT statement in your view. There are
multiple ways to skin a cat, some are better and others are worse.
At least we could see, if you use something that causes the optimizer to use
a table scan instead of an index acces.
Or you may have multiple sub-selects that can be put into a single one.
Also we may be able to suggest some indexes that might be used by the query

Also it might be helpful if you show some WHERE conditions you want to add
to your SELECT statement.
And using SELECT * may not be a good decision either, just select the
columns you really need.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
?Train people well enough so they can leave, treat them well enough so they
don't want to.? (Richard Branson)

-----Original Message-----
From: RPG400-L <rpg400-l-bounces@xxxxxxxxxxxx> On Behalf Of Thomas Garvey
Sent: Freitag, 24. August 2018 22:37
To: rpg400-l@xxxxxxxxxxxx
Subject: Re: [EXTERNAL] SQL Views worth it?

I appreciate all the comments.
I have tried using the Visual Explain, hopeful that it might suggest an
index or two, but I get nothing.

I don't know if screen shots will get through here but, here's the visual of
a view I'm working on.

Seems complicated enough that the Advisor would come up with something.

But here's what I get, and it doesn't matter which step of the visual I
click on and select.

Maybe I don't know how to use this tool correctly?

Best Regards,

Thomas Garvey

On 8/24/2018 3:19 PM, Greg Wilburn wrote:
I have views that join (many) other views. Many of those views have
views/joins imbedded inside them.

Some of these are over very large files on a very small system (P05).
After running index advisor & building some of the suggested indexes, I have
ZERO performance issues. Again, this is just my experience.


-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Alan
Sent: Friday, August 24, 2018 3:25 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: RE: [EXTERNAL] SQL Views worth it?

Hi Thomas
It depends on how "complicated" the views are and how they need to be used
For example - we have a view that shows the packages that were shipped
within the last 30 days I don't think that's feasible in a logical file,
whereas a view can compare the shipped_date to the current_date

Alan Shore
E-mail : ASHORE@xxxxxxxx
Phone [O] : (631) 200-5019
Phone [C] : (631) 880-8640
'If you're going through hell, keep going.'
Winston Churchill

-----Original Message-----
From: RPG400-L [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Thomas
Sent: Friday, August 24, 2018 2:11 PM
To: RPG programming on the IBM i (AS/400 and iSeries)
Subject: [EXTERNAL] 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 thread ...


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

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 [javascript protected email address].