RE: Record Length -- MIDRANGE-L

I would agree. I thought you were talking about having multiple versions of
the address based on changes. What you did is exactly what I described in
respect to storing the snapshot of the address in the invoice header. Sorry
about the confusion.

-----Original Message-----
From: Jim Langston [mailto:jlangston@conexfreight.com]
Sent: Monday, October 25, 1999 12:35 PM
To: MIDRANGE-L@midrange.com
Subject: Re: Record Length




Alan Campin wrote:

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

The reason for normalization is to not duplicate data needlessly.  The way
your
are speaking of here would just move the data from the header to the the
separate

table, it would not reduce data in any way, but would in fact increase it a
little
(since the new table would have to reinclude the invoice number and other
key
information) and this would solve nothing.

No program logic was involved, actually.  When they create the invoice, it
copies

the information from the customer data base into the invoice header.  Any
time
I am printing out invoice I print the information contained in the header,
not
even
linking to the customer file.

Any SQL would work perfect on this (and in fact was written in Clipper 5.0,
a
SQL type language).

You have to understand, all customer information was copied to the invoice
header

for all invoices.  It wasn't on an exception basis at that point, whenever
an
invoice
was copied the 5 addressing fields were copied to the invoice header, and
all
programs
then used the address in the invoice header when dealing with that invoice.

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

I don't quite understand, because it seems that what you described above is
exactly what I did.  When the invoice was created I placed the address into
the invoice header.

Perhaps I just hadn't explained what I did very well.

Regards,

Jim Langston

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

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