View Single Post
  #15  
Old April 9th, 2010, 08:46 PM posted to microsoft.public.access.tablesdbdesign
hollyylloh
external usenet poster
 
Posts: 18
Default Interested in thoughts on keeping the integrity of historical

Steve,

I am not suggesting that I would use a single table design. I am talking
about using a table to store the data derived from a multi-table design. The
reports would then pull from the storage table.

I understand what you are talking about with Client and ClientAddress
tables, and I understand this is the normal and correct way to design
relational databases.

The reason I am considering stepping away from the normal design scenario is
1) to insure historical accuracy and 2) in a effort to make the user
interface very simple.


"Steve" wrote:

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



.