Re: Performance of ODBC vs. other access methods

Steve - this comment of Richard's is about vendor updates, not persistent and 
continual maintenance and administration - i fear your comments do not address 
the point made.

Regards
Vern

-------------- Original message -------------- 
From: "Steve Richter" <stephenrichter@xxxxxxxxx> 

On 9/6/06, richard@xxxxxxxxxxx wrote: 

Here's a thought. In fact we've run into this with people building custom 
indexes over our WebDocs Document Management tables: 

Build logical files or SQL views where needed to support inquiries. Just 
make sure not to specify UNIQUE for any of the keys. 

As long as you don't specifiy UNIQUE on the keys, you can get the 
performance needed without causing problems. 

I don't think too many vendor packages rebuild tables on a regular basis 
any more. Hopefully :-) 

Then create a CL program that gets run each time you apply a vendor update 
that deletes your custom views and indexes and rebuilds them after the 
vendor update. 

Think of this as similar to the customization you would do after an OS/400 
upgrade. I always advocate storing customizations in a CL program that 
gets run after the OS/400 upgrade. 

Short of that you just have to be very careful with testing when you write 
queries against your DB. Use existing keys in your queries and you should 
be able to get sub-second response times. 

Sounds like the i5 needs just as much administering to keep it running 
as other systems. Selling the i5 at p5 prices would give us quad core 
systems in place of the single and even fractional cores available in 
the typical i5. With that kind of speed there would be no concern 
about just in time index builds. 

-Steve 
-- 
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list 
To post a message email: MIDRANGE-L@xxxxxxxxxxxx 
To subscribe, unsubscribe, or change list options, 
visit: http://lists.midrange.com/mailman/listinfo/midrange-l 
or email: MIDRANGE-L-request@xxxxxxxxxxxx 
Before posting, please take a moment to review the archives 
at http://archive.midrange.com/midrange-l.