Re: How the SQL Server World Lives

sure they do indexing, it's a capacity issue I guess. It's also a very
autocratic place the DBA is the tyrant. you can't just make changes it has
to go thru the committee.
No I would rather be back on the 400 but that will take a small miracle,
make that a large one.

On Wed, Jan 30, 2013 at 8:58 AM, Richard Schoen <richard@xxxxxxxxxxxxxxx>wrote:

I used to say to them many times, what a shame, I never had this issue back
on the 400. Now I just accept it and move on to the next task.

Rather than simply accepting your fate have you ever tried imparting your
knowledge of database indexing on the new generation ?

I have found many times that inadequate indexing of tables has caused
issue with SQL server.

Same issue can be had on iSeries if SQL or OPNQRYF is used and a bad DB
design is in place with inadequate joinable indexes on the tables.

I feel lucky I grew up in the ISAM age because it provided perspective on
adequate indexing.

Back in the late 80's I wrote an interactive sales inquiry over a 6
million record table and it made the lights dim. It worked, but it was
poorly designed for an interactive environment.

A little SQL Server profiling and some indexes could change the app
completely unless your server resources are simply overcommitted.

Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business
Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site: http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT

------------------------------

message: 4
date: Wed, 30 Jan 2013 08:46:23 -0500
from: Hoteltravelfundotcom <hoteltravelfun@xxxxxxxxx>
subject: Re: How the SQL Server World Lives

I have been on Sql server and Oracle for past 4 years after starting on
System 34 (1981) and AS/400 in 1989. For me, worse than the corruption
issue, which to date I have seen a few times here, but far worse from my
perspective is how slow both Oracle and SQL Server are. I never had such an
issue where because there are so many records to read, we can't deploy a
simple program. It was far easier to make whatever job adjustments you had
to make and provide the user with their report or screen. Here after
developing some tabs, we had to put some on hold, while we wait for the
other team to provide the data for us in a better way.

I used to say to them many times, what a shame, I never had this issue back
on the 400. Now I just accept it and move on to the next task.




--
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.