Storing all the data, that has historical significance, in a single table is
a very bad idea! In a single table design, you would need to type in the
address for each transaction. What happens if a user mistypes a part of an
address that was previously used by your client. Now you have two addesses
for the client when actually it should be one - the client used the same
address both times. The correct design is a TblClient and a
TblClientAddress. You just need to select the correct client address at each
transaction. If the client has a new address at the time of the transaction,
you need to first add the new address to TblClientAddress and then select
the new address as you enter the transaction.

Steve



"hollyylloh" wrote in message
...
Fred, thank you for your thoughts. Just to be clear, I think you are
agreeing
with my first inclination as stated above? In saying "databasing the
entire
transaction event" do you mean: Store all the data, that has historical
significance, in a single table? Thanks again.

"Fred" wrote:

In the example that you gave, you used a transaction as an example of a
case
where you needed the historical data (e.g. address) This is an example of
a
common areas where this is needed. If this is the main need, you might
want
to start databasing the entire transaction events (e.g. invoices, e.g.
including the at-the-time billing address) as entities. (vs. treating
only
certain items in them as entities, and "deriving" the invoice each time
that
it is printed.)