RE: Record Length

>>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:jlangston@conexfreight.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:
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
+---