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