>>I can think of one example of when I needed to un-normalize a data base How about just normalizing the structure to place the address in a separate table with a key of invoice number and address type? Maybe original and corrected or something to that level. Still not real comfortable with that since you would need program logic to determine which address to use. My general rule of thumb is that I must be able to process it with an SQL. If I can't then I have an abnormal data structure exception being a recursive structure( Bill of Material) types. How about current flag? Each address given a sequential number and a flag that specifies the record as current? >>I had linked the customer database to the invoice header via the customer number. I think it would always be good practice to place the address at invoice time into the invoice header or a normalized table attached to the invoice header. This represents what the address was at invoice time, not what it was currently. If you wanted a way to update it, you might be able to use the table structure above. The vendor of our package uses that approach (Snapshot) and I think it is a valid one. -----Original Message----- From: Jim Langston [mailto:email@example.com] Sent: Monday, October 25, 1999 9:01 AM To: MIDRANGE-L@midrange.com Subject: Re: Record Length I can think of one example of when I needed to un-normalize a data base. I had written a retail management program that did everything for a small business, inventory, invoice, A/R, A/P, etc.. I had linked the customer database to the invoice header via the customer number. What would happen is sometimes there would need to be special addressing for an invoice. So I added a user changeable field to allow for this. Then a few customers moved, and when the invoices were reprinted it would show the new information, and not the old information, but my client wanted the old information to show. So I duplicated all the addressing information from the customer database into the invoice header, and when an invoice was created moved the fields over and allowed them to change any of the information they wanted. That fixed all the issues, and also meant I didn't have to go back again to deal with the same type of issues. Regards, Jim Langston PaulMmn wrote: > As much as I like a nice, normalized database, there have been times where > un-normalizing a database is the most effective solution. > > Of course, I can't think of a good example right now. > > However, I do insist that the database MUST be normalized to at least 3rd > normal form at some point in the development process. > > The discipline of normalizing the data is the important part. You need to > split the data into its optimum records before you can un-normalize it. > > --Paul E Musselman > PaulMmn@ix.netcom.com > > >Well, of course, Alan. If he has to denormalize it to do it, there is no > >good reason to do it. Database files should *always* be normalized. > > > >Scott didn't mention anything about normalization though. Which is why > >I asked the question, better for what? > > > >Regards, > > > >Jim Langston > > > >Alan Campin wrote: > > > >> 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. > > > >[SNIP] > > +--- > | 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: firstname.lastname@example.org > +--- +--- | 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: email@example.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: firstname.lastname@example.org +---
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.