× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Sorry but I disagree strongly.

Your tables should be normalized. If all the attributes(fields) in the table
is based on the key and nothing but the key, then you know what size your
record is. The data base normalization tells you what goes in each table.

The rule of data base design has always been to normalize to, at least,
third normal form and denormalize only if you run into a performance issue
and even then look at your code. For example, are you using READE instead
READ in a loop. If you use READ, the performance of a table will increase
rapidly. The other thing to consider is using logicals that select only the
fields you need in the program (What I call an application logical). Your
program will be also smaller and use less static storage and will run
faster. Bringing in only data you need will increase performance
considerably. Also, consider using field select join logicals whenever
possible. Instead of using two or three CHAIN's you use one and the data
base does all the reads at the machine buffer level, ie faster. 

If you need information on field select logicals, I sent out a post a few
weeks ago that detail the process that I could resend. 

The AS/400 is a relational data base and all relational data bases are
optimized for small records and many tables. IBM may have detuned the AS/400
data base to deal with the massive unnormalized tables that exist but I
don't know that. I just know that a properly normalized table cooks. I have
been building normalized tables on the AS/400 and System 38 for 15 years and
I have never run into a situation on the AS/400 where I had to denormalize a
table because of performance reasons. There may be conditions but I bet they
are pretty rare.

I always shudder when I see someone designing a table without normalizing.
If you look at most programs using denormalized tables, most of the code is
being used to deal with the denormalized data base rather than have it
handled in the data base. If the data base is normalized correctly, then the
code to use it should be very simple. Unnormalized and you have a mess. 

All this simply means is the data base is paramount. Everything flows from
the data base.

Thanks for the opportunity to discuss this issue. 

Alan Campin
Case Logic, Inc
Longmont, CO 
-----Original Message-----
From: Jim Langston [mailto:jlangston@conexfreight.com]
Sent: Wednesday, October 13, 1999 2:14 PM
To: MIDRANGE-L@midrange.com
Subject: Re: Record Length


I would say a longer record length and less records, because there
would actually be fewer reads if going through all the records.

That is just my understanding, though, as I have not done any tests
on this.

But it also seems to be that any logicals put over such a file would be
shorter by half also.  Which would save DASD and perhaps speed things
up a bit.

The question I have, is better for what?

Regards,

Jim Langston

Scott Swaim wrote:

> Is it better to have a shorter record length and more records
> or a longer record length and less records?
>
> ex:
>
> Rcd length =   80       # of rcds = 10,000 OR
> Rcd length = 160       # of rcds = 5,000
>
> Scott Swaim
> scott@qualitycorps.com
>
> +---
> | This is the Midrange System Mailing List!
> | To submit a new message, send your mail to MIDRANGE-L@midrange.com.
> | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
> | To unsubscribe from this list send email to
MIDRANGE-L-UNSUB@midrange.com.
> | Questions should be directed to the list owner/operator:
david@midrange.com
> +---

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator:
david@midrange.com
+---
+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

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

This mailing list archive is Copyright 1997-2024 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].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.