|
 |
access thread: Transaction History
Message #1 by "Enzo Zaragoza" <enzaux@g...> on Fri, 29 Nov 2002 10:39:31 +0800
|
|
Hello!!! I would like to have your opinions on my query. Here is my situation:
I'm doing a remittance system. I want to know what's the best way my transaction table
be set up. I have a Transaction table (tblTranx), Sender Table (tblSender) and Benificiaries'
table (tblBene).
tblTranx tblSender tblBene
------------------------------------------------
TranxID
SenderID M--1 SenderID 1--M SenderID
BeneID BeneID
^M----------------------------------1^
A transaction contains the following:
1.) Sender & Beneficiary
- name
- address
- tel no
- cell no
- other infos
2.) Amount to be remitted
3.) Other Infos
What I'm concerned with is the Sender and Bene part. What I want know is which is better
to do with the Sender and Bene info, to have only tblTranx.SenderID be linked only to
tblSender.SenderID or to create fields in tblTranx for Sender and Bene Infos such as name, addr, etc ?
Taking into considerations that if the Sender and Bene have changes in their info in the near future.
Currently what I'm doing right now is the second option (created fields in tblTranx for Sender
and Bene Info) because if the sender or bene changes any of its information at least the past transactions
would not be affected since tblTranx has fields that stored the info.
Am I doing the right way? Or are there any better options than these? Because with the option I use,
bloated database is all I have because repeated infos are stored on tblTranx. Any tips and suggestions?
Thanks,
Enzo c",)
YahooID: yackydidakdak
Message #2 by "Haslett, Andrew" <andrew.haslett@i...> on Fri, 29 Nov 2002 14:24:52 +1030
|
|
Why does it matter if sender or beneficiaries details change?
Is it important than an old transaction retain (be linked to) those details
AT THAT TIME?
If it is, then there's no way around storing their details with every
transaction.
If not, then it won't matter storing their details once in the senders and
beneficiaries table.
Think of it this way:
If you are producing a report listing all transactions, do you want to show
the sender and beneficiaries details for EVERY transaction, as they were at
the time of the transaction.. or only once, as they are now...
Cheers,
A
-----Original Message-----
From: Enzo Zaragoza [mailto:enzaux@g...]
Sent: Friday, 29 November 2002 1:10 PM
To: Access
Subject: [access] Transaction History
Hello!!! I would like to have your opinions on my query. Here is
my situation:
I'm doing a remittance system. I want to know what's the best way my
transaction table
be set up. I have a Transaction table (tblTranx), Sender Table (tblSender)
and Benificiaries'
table (tblBene).
tblTranx tblSender tblBene
------------------------------------------------
TranxID
SenderID M--1 SenderID 1--M SenderID
BeneID BeneID
^M----------------------------------1^
A transaction contains the following:
1.) Sender & Beneficiary
- name
- address
- tel no
- cell no
- other infos
2.) Amount to be remitted
3.) Other Infos
What I'm concerned with is the Sender and Bene part. What I want
know is which is better
to do with the Sender and Bene info, to have only tblTranx.SenderID be
linked only to
tblSender.SenderID or to create fields in tblTranx for Sender and Bene Infos
such as name, addr, etc ?
Taking into considerations that if the Sender and Bene have changes in their
info in the near future.
Currently what I'm doing right now is the second option (created
fields in tblTranx for Sender
and Bene Info) because if the sender or bene changes any of its information
at least the past transactions
would not be affected since tblTranx has fields that stored the info.
Am I doing the right way? Or are there any better options than
these? Because with the option I use,
bloated database is all I have because repeated infos are stored on
tblTranx. Any tips and suggestions?
Thanks,
Enzo c",)
YahooID: yackydidakdak
IMPORTANT - PLEASE READ ********************
This email and any files transmitted with it are confidential and may
contain information protected by law from disclosure.
If you have received this message in error, please notify the sender
immediately and delete this email from your system.
No warranty is given that this email or files, if attached to this
email, are free from computer viruses or other defects. They
are provided on the basis the user assumes all responsibility for
loss, damage or consequence resulting directly or indirectly from
their use, whether caused by the negligence of the sender or not.
Message #3 by "Enzo Zaragoza" <enzaux@g...> on Fri, 29 Nov 2002 12:53:12 +0800
|
|
It does matter because sometimes there are it's for back tracking purposes for
example if a person was not reached thru his new telephone number they will resort
checking his old records and get the previous telephone number the sender/bene has.
Thanks,
enzo c",)
-----Original Message-----
From: Haslett, Andrew [mailto:andrew.haslett@i...]
Sent: Friday, November 29, 2002 11:55 AM
To: Access
Subject: [access] RE: Transaction History
Why does it matter if sender or beneficiaries details change?
Is it important than an old transaction retain (be linked to) those details
AT THAT TIME?
If it is, then there's no way around storing their details with every
transaction.
If not, then it won't matter storing their details once in the senders and
beneficiaries table.
Think of it this way:
If you are producing a report listing all transactions, do you want to show
the sender and beneficiaries details for EVERY transaction, as they were at
the time of the transaction.. or only once, as they are now...
Cheers,
A
-----Original Message-----
From: Enzo Zaragoza [mailto:enzaux@g...]
Sent: Friday, 29 November 2002 1:10 PM
To: Access
Subject: [access] Transaction History
Hello!!! I would like to have your opinions on my query. Here is
my situation:
I'm doing a remittance system. I want to know what's the best way my
transaction table
be set up. I have a Transaction table (tblTranx), Sender Table (tblSender)
and Benificiaries'
table (tblBene).
tblTranx tblSender tblBene
------------------------------------------------
TranxID
SenderID M--1 SenderID 1--M SenderID
BeneID BeneID
^M----------------------------------1^
A transaction contains the following:
1.) Sender & Beneficiary
- name
- address
- tel no
- cell no
- other infos
2.) Amount to be remitted
3.) Other Infos
What I'm concerned with is the Sender and Bene part. What I want
know is which is better
to do with the Sender and Bene info, to have only tblTranx.SenderID be
linked only to
tblSender.SenderID or to create fields in tblTranx for Sender and Bene Infos
such as name, addr, etc ?
Taking into considerations that if the Sender and Bene have changes in their
info in the near future.
Currently what I'm doing right now is the second option (created
fields in tblTranx for Sender
and Bene Info) because if the sender or bene changes any of its information
at least the past transactions
would not be affected since tblTranx has fields that stored the info.
Am I doing the right way? Or are there any better options than
these? Because with the option I use,
bloated database is all I have because repeated infos are stored on
tblTranx. Any tips and suggestions?
Thanks,
Enzo c",)
YahooID: yackydidakdak
IMPORTANT - PLEASE READ ********************
This email and any files transmitted with it are confidential and may
contain information protected by law from disclosure.
If you have received this message in error, please notify the sender
immediately and delete this email from your system.
No warranty is given that this email or files, if attached to this
email, are free from computer viruses or other defects. They
are provided on the basis the user assumes all responsibility for
loss, damage or consequence resulting directly or indirectly from
their use, whether caused by the negligence of the sender or not.
Message #4 by "Enzo Zaragoza" <enzaux@g...> on Fri, 29 Nov 2002 13:08:04 +0800
|
|
Sorry I have typo and grammar error :D
It does matter because sometimes they back track sender/bene history. For
example if a person was not reached thru his new telephone number they will resort
checking his old records and get the previous telephone number the sender/bene has.
Thanks,
enzo c",)
-----Original Message-----
From: Enzo Zaragoza [mailto:enzaux@g...]
Sent: Friday, November 29, 2002 12:53 PM
To: Access
Subject: [access] RE: Transaction History
It does matter because sometimes there are it's for back tracking purposes for
example if a person was not reached thru his new telephone number they will resort
checking his old records and get the previous telephone number the sender/bene has.
Thanks,
enzo c",)
-----Original Message-----
From: Haslett, Andrew [mailto:andrew.haslett@i...]
Sent: Friday, November 29, 2002 11:55 AM
To: Access
Subject: [access] RE: Transaction History
Why does it matter if sender or beneficiaries details change?
Is it important than an old transaction retain (be linked to) those details
AT THAT TIME?
If it is, then there's no way around storing their details with every
transaction.
If not, then it won't matter storing their details once in the senders and
beneficiaries table.
Think of it this way:
If you are producing a report listing all transactions, do you want to show
the sender and beneficiaries details for EVERY transaction, as they were at
the time of the transaction.. or only once, as they are now...
Cheers,
A
-----Original Message-----
From: Enzo Zaragoza [mailto:enzaux@g...]
Sent: Friday, 29 November 2002 1:10 PM
To: Access
Subject: [access] Transaction History
Hello!!! I would like to have your opinions on my query. Here is
my situation:
I'm doing a remittance system. I want to know what's the best way my
transaction table
be set up. I have a Transaction table (tblTranx), Sender Table (tblSender)
and Benificiaries'
table (tblBene).
tblTranx tblSender tblBene
------------------------------------------------
TranxID
SenderID M--1 SenderID 1--M SenderID
BeneID BeneID
^M----------------------------------1^
A transaction contains the following:
1.) Sender & Beneficiary
- name
- address
- tel no
- cell no
- other infos
2.) Amount to be remitted
3.) Other Infos
What I'm concerned with is the Sender and Bene part. What I want
know is which is better
to do with the Sender and Bene info, to have only tblTranx.SenderID be
linked only to
tblSender.SenderID or to create fields in tblTranx for Sender and Bene Infos
such as name, addr, etc ?
Taking into considerations that if the Sender and Bene have changes in their
info in the near future.
Currently what I'm doing right now is the second option (created
fields in tblTranx for Sender
and Bene Info) because if the sender or bene changes any of its information
at least the past transactions
would not be affected since tblTranx has fields that stored the info.
Am I doing the right way? Or are there any better options than
these? Because with the option I use,
bloated database is all I have because repeated infos are stored on
tblTranx. Any tips and suggestions?
Thanks,
Enzo c",)
YahooID: yackydidakdak
IMPORTANT - PLEASE READ ********************
This email and any files transmitted with it are confidential and may
contain information protected by law from disclosure.
If you have received this message in error, please notify the sender
immediately and delete this email from your system.
No warranty is given that this email or files, if attached to this
email, are free from computer viruses or other defects. They
are provided on the basis the user assumes all responsibility for
loss, damage or consequence resulting directly or indirectly from
their use, whether caused by the negligence of the sender or not.
Message #5 by "Bob Bedell" <bobbedell15@m...> on Fri, 29 Nov 2002 05:14:12 +0000
|
|
Hi Enzo,
Just a couple of thoughts.
Why would it be necessary to store the SenderID in the Beneficiary
table? Is it possible for a beneficiary to recieve a remittance from
more than one sender? Seems likely. If so, the two entities are linked,
and can be matched, through the Transaction table, which serves as a
junction table.
tblSender tblTranx tblBene
-----------------------------------------
SenderID 1--M SenderID
BeneID M--1 BeneID
SenderID and BeneID would be composite primary keys/foreign keys in the
transaction table, or you could add a TransID field and create a unique
index on the foreign keys.
Second, I can't imagine that storing beneficiary details in the
transactions table would be a necessary or optimal solution. If current
information is obsolete, it seems even more likely that historical
information would be too. But if the historical information is needed,
perhaps the place to put it would be in some type of archive table with
a one-to-one relationship with the beneficiary table. Its hard to
imagine though that it would belong in the transaction table.
Best,
Bob
>From: "Enzo Zaragoza" <enzaux@g...>
>Reply-To: "Access" <access@p...>
>To: "Access" <access@p...>
>Subject: [access] RE: Transaction History
>Date: Fri, 29 Nov 2002 12:53:12 +0800
>
>
> It does matter because sometimes there are it's for back tracking purposes
>for
>example if a person was not reached thru his new telephone number they will
>resort
>checking his old records and get the previous telephone number the
>sender/bene has.
>
>Thanks,
>
>enzo c",)
>
>-----Original Message-----
>From: Haslett, Andrew [mailto:andrew.haslett@i...]
>Sent: Friday, November 29, 2002 11:55 AM
>To: Access
>Subject: [access] RE: Transaction History
>
>
>Why does it matter if sender or beneficiaries details change?
>
>Is it important than an old transaction retain (be linked to) those details
>AT THAT TIME?
>
>If it is, then there's no way around storing their details with every
>transaction.
>
>If not, then it won't matter storing their details once in the senders and
>beneficiaries table.
>
>Think of it this way:
>If you are producing a report listing all transactions, do you want to show
>the sender and beneficiaries details for EVERY transaction, as they were at
>the time of the transaction.. or only once, as they are now...
>
>Cheers,
>A
>
>-----Original Message-----
>From: Enzo Zaragoza [mailto:enzaux@g...]
>Sent: Friday, 29 November 2002 1:10 PM
>To: Access
>Subject: [access] Transaction History
>
>
>
> Hello!!! I would like to have your opinions on my query. Here is
>my situation:
>
> I'm doing a remittance system. I want to know what's the best way
>my
>transaction table
>be set up. I have a Transaction table (tblTranx), Sender Table (tblSender)
>and Benificiaries'
>table (tblBene).
>
>tblTranx tblSender tblBene
>------------------------------------------------
>TranxID
>SenderID M--1 SenderID 1--M SenderID
>BeneID BeneID
> ^M----------------------------------1^
>
> A transaction contains the following:
>1.) Sender & Beneficiary
> - name
> - address
> - tel no
> - cell no
> - other infos
>
>2.) Amount to be remitted
>3.) Other Infos
>
> What I'm concerned with is the Sender and Bene part. What I want
>know is which is better
>to do with the Sender and Bene info, to have only tblTranx.SenderID be
>linked only to
>tblSender.SenderID or to create fields in tblTranx for Sender and Bene
>Infos
>such as name, addr, etc ?
>Taking into considerations that if the Sender and Bene have changes in
>their
>info in the near future.
>
> Currently what I'm doing right now is the second option (created
>fields in tblTranx for Sender
>and Bene Info) because if the sender or bene changes any of its information
>at least the past transactions
>would not be affected since tblTranx has fields that stored the info.
>
> Am I doing the right way? Or are there any better options than
>these? Because with the option I use,
>bloated database is all I have because repeated infos are stored on
>tblTranx. Any tips and suggestions?
>
>Thanks,
>
>
>Enzo c",)
>YahooID: yackydidakdak
>
>
>
>IMPORTANT - PLEASE READ ********************
>This email and any files transmitted with it are confidential and may
>contain information protected by law from disclosure.
>If you have received this message in error, please notify the sender
>immediately and delete this email from your system.
>No warranty is given that this email or files, if attached to this
>email, are free from computer viruses or other defects. They
>are provided on the basis the user assumes all responsibility for
>loss, damage or consequence resulting directly or indirectly from
>their use, whether caused by the negligence of the sender or not.
>
>
>
>
>
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Message #6 by "Bob Bedell" <bobbedell15@m...> on Fri, 29 Nov 2002 05:27:12 +0000
|
|
Or simply have a table for known phone numbers/addresses with a boolean
field that flags active/inactive info. Establish a 1:M relationship
between this table and the beneficiary table. Use a date stamp of some
sort if you'ld ever need to match that info to transactions.
>From: "Bob Bedell" <bobbedell15@m...>
>Reply-To: "Access" <access@p...>
>To: "Access" <access@p...>
>Subject: [access] RE: Transaction History
>Date: Fri, 29 Nov 2002 05:14:12 +0000
>
>Hi Enzo,
>
>Just a couple of thoughts.
>
>Why would it be necessary to store the SenderID in the Beneficiary
>table? Is it possible for a beneficiary to recieve a remittance from
>more than one sender? Seems likely. If so, the two entities are linked,
>and can be matched, through the Transaction table, which serves as a
>junction table.
>
>tblSender tblTranx tblBene
>-----------------------------------------
>SenderID 1--M SenderID
> BeneID M--1 BeneID
>
>SenderID and BeneID would be composite primary keys/foreign keys in the
>transaction table, or you could add a TransID field and create a unique
>index on the foreign keys.
>
>Second, I can't imagine that storing beneficiary details in the
>transactions table would be a necessary or optimal solution. If current
>information is obsolete, it seems even more likely that historical
>information would be too. But if the historical information is needed,
>perhaps the place to put it would be in some type of archive table with
>a one-to-one relationship with the beneficiary table. Its hard to
>imagine though that it would belong in the transaction table.
>
>Best,
>
>Bob
>
>>From: "Enzo Zaragoza" <enzaux@g...>
>>Reply-To: "Access" <access@p...>
>>To: "Access" <access@p...>
>>Subject: [access] RE: Transaction History
>>Date: Fri, 29 Nov 2002 12:53:12 +0800
>>
>>
>> It does matter because sometimes there are it's for back tracking
>>purposes for
>>example if a person was not reached thru his new telephone number they
>>will resort
>>checking his old records and get the previous telephone number the
>>sender/bene has.
>>
>>Thanks,
>>
>>enzo c",)
>>
>>-----Original Message-----
>>From: Haslett, Andrew [mailto:andrew.haslett@i...]
>>Sent: Friday, November 29, 2002 11:55 AM
>>To: Access
>>Subject: [access] RE: Transaction History
>>
>>
>>Why does it matter if sender or beneficiaries details change?
>>
>>Is it important than an old transaction retain (be linked to) those
>>details
>>AT THAT TIME?
>>
>>If it is, then there's no way around storing their details with every
>>transaction.
>>
>>If not, then it won't matter storing their details once in the senders and
>>beneficiaries table.
>>
>>Think of it this way:
>>If you are producing a report listing all transactions, do you want to
>>show
>>the sender and beneficiaries details for EVERY transaction, as they were
>>at
>>the time of the transaction.. or only once, as they are now...
>>
>>Cheers,
>>A
>>
>>-----Original Message-----
>>From: Enzo Zaragoza [mailto:enzaux@g...]
>>Sent: Friday, 29 November 2002 1:10 PM
>>To: Access
>>Subject: [access] Transaction History
>>
>>
>>
>> Hello!!! I would like to have your opinions on my query. Here is
>>my situation:
>>
>> I'm doing a remittance system. I want to know what's the best way
>>my
>>transaction table
>>be set up. I have a Transaction table (tblTranx), Sender Table
>>(tblSender)
>>and Benificiaries'
>>table (tblBene).
>>
>>tblTranx tblSender tblBene
>>------------------------------------------------
>>TranxID
>>SenderID M--1 SenderID 1--M SenderID
>>BeneID BeneID
>> ^M----------------------------------1^
>>
>> A transaction contains the following:
>>1.) Sender & Beneficiary
>> - name
>> - address
>> - tel no
>> - cell no
>> - other infos
>>
>>2.) Amount to be remitted
>>3.) Other Infos
>>
>> What I'm concerned with is the Sender and Bene part. What I want
>>know is which is better
>>to do with the Sender and Bene info, to have only tblTranx.SenderID be
>>linked only to
>>tblSender.SenderID or to create fields in tblTranx for Sender and Bene
>>Infos
>>such as name, addr, etc ?
>>Taking into considerations that if the Sender and Bene have changes in
>>their
>>info in the near future.
>>
>> Currently what I'm doing right now is the second option (created
>>fields in tblTranx for Sender
>>and Bene Info) because if the sender or bene changes any of its
>>information
>>at least the past transactions
>>would not be affected since tblTranx has fields that stored the info.
>>
>> Am I doing the right way? Or are there any better options than
>>these? Because with the option I use,
>>bloated database is all I have because repeated infos are stored on
>>tblTranx. Any tips and suggestions?
>>
>>Thanks,
>>
>>
>>Enzo c",)
>>YahooID: yackydidakdak
>>
>>
>>
>>IMPORTANT - PLEASE READ ********************
>>This email and any files transmitted with it are confidential and may
>>contain information protected by law from disclosure.
>>If you have received this message in error, please notify the sender
>>immediately and delete this email from your system.
>>No warranty is given that this email or files, if attached to this
>>email, are free from computer viruses or other defects. They
>>are provided on the basis the user assumes all responsibility for
>>loss, damage or consequence resulting directly or indirectly from
>>their use, whether caused by the negligence of the sender or not.
>>
>>
>>
>>
>>
>
>
>_________________________________________________________________
>Protect your PC - get McAfee.com VirusScan Online
>http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>
>---
>Change your mail options at http://p2p.wrox.com/manager.asp or to
>unsubscribe send a blank email to
_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus
Message #7 by "Charlie Goodwin" <cgoodwin@c...> on Fri, 29 Nov 2002 00:35:39 -0500
|
|
Enzo,
Maybe you need only one unified table for all the people giving and receivi
ng money, since you probably are storing essentially the same data for each?
If you make a TblPeople with say:
PeopleID Autonumber
Name Text
Address Text
Ph Text
etc
And a TblTranx with say:
TranxID Autonumber
SenderID Number
BeneID Number
AmountRem Number
etc
To create records of Transactions, a combo/list with TblPeople as the sourc
e can supply PeopleIDs for senders and receivers for TblTranx.
But, how to work with reports for tables that have more than one link to ea
ch other?
Connect senders and receivers both from the TblPeople via creating two inst
ances of the TblPeople in the query window: in the query design window add
TblPeople --- twice
Select Properties for each TblPeople. Go to the line for alias.
In this case I set them to: YourSenderAlias and YourBeneAlias:
so, choose one and make it something like YourSenderAlias
Choose the other and make it something like YourBeneAlias
Now add TblTranx to the query design window
Drag each PeopleID from their respective instance of TblPeople:from YourSen
derAlias to the senderID in TblTranx and from YourBeneAlias to BeneID in Tb
lTranx. You have just made the link that distinguishes Senders from Benes.
Drag IDs, Name, Address, Ph from each people table and Tranx ID and AmountR
em into the design grid
Your result in the SQL view should come out something like this:
SELECT DISTINCTROW TblTranx.TranxID, TblTranx.AmountRemit, YourSenderAlias.
PeopleID, YourSenderAlias.Name, YourSenderAlias.Address, YourSenderAlias.Ph
, YourBeneAlias.PeopleID, YourBeneAlias.Name, YourBeneAlias.Address, YourBe
neAlias.Ph
FROM TblPeople AS YourBeneAlias INNER JOIN (TblPeople AS YourSenderAlias IN
NER JOIN TblTranx ON YourSenderAlias.PeopleID =3D TblTranx.SenderID) ON You
rBeneAlias.PeopleID =3D TblTranx.BeneID;
You can report senders and Benes and their addresses and Phones etc and lab
el them for which each is in reports.
Something that would make data entry easier would be to add a field in TblP
eople, a number field, PeopleTypes, perhaps:
1 for Senders
2 for Benes
?3 for someone who might be both a sender and a bene???
Then you could base your combo/lists for data entry into TblTranx on querie
s that would only show Benes in their field and Senders in their field. D
epending on the setup other schemes might be better for paring down the lis
ts for Adding data into TblTranx, but this will give you ideas.
If you ever had to deal with more types of people, you could add other valu
es for the PeopleTypes field.
A scheme like this should reduce bloat and errors dramatically, and make da
ta entry much much easier.
In my art database, I have one table for art show details that connects to
my table for people and Contact organizations in the way listed above, with
3 different aliases: ShowSponsor, ShowPhysicalLocation, and ShowCurator.
Sorry for being so long winded. Let me know if this helps.
Charlie
Original Message_______________________________
From: Enzo Zaragoza [enzaux@g...] To: Access [access@p...]
Transaction History Time: 11/28/02 at 9:39PM
Hello!!! I would like to have your opinions on my query. Here is my situa
tion:
I'm doing a remittance system. I want to know what's the best way my trans
action table
be set up. I have a Transaction table (tblTranx), Sender Table (tblSender)
and Benificiaries'
table (tblBene).
tblTranx tblSender tblBene
------------------------------------------------
TranxID
SenderID M--1 SenderID 1--M SenderID
BeneID BeneID
^M----------------------------------1^
A transaction contains the following:
1.) Sender & Beneficiary
- name
- address
- tel no
- cell no
- other infos
2.) Amount to be remitted
3.) Other Infos
What I'm concerned with is the Sender and Bene part. What I want know is
which is better
to do with the Sender and Bene info, to have only tblTranx.SenderID be link
ed only to
tblSender.SenderID or to create fields in tblTranx for Sender and Bene Info
s such as name, addr, etc ?
Taking into considerations that if the Sender and Bene have changes in thei
r info in the near future.
Currently what I'm doing right now is the second option (created fields in
tblTranx for Sender
and Bene Info) because if the sender or bene changes any of its information
at least the past transactions
would not be affected since tblTranx has fields that stored the info.
Am I doing the right way? Or are there any better options than these? Be
cause with the option I use,
bloated database is all I have because repeated infos are stored on tblTran
x. Any tips and suggestions?
Thanks,
Enzo c",)
YahooID: yackydidakdak
Message #8 by "Enzo Zaragoza" <enzaux@g...> on Fri, 29 Nov 2002 14:10:08 +0800
|
|
Bene is related only to one Sender or in other words
a single Sender have many Bene. That's explain why I have the
Sender ID in the tblBene. Here are the steps during the transaction:
1.) Select a sender
2.) A list of beneficiaries RELATED to Sender is shown
3.) Select beneficiary
4.) other process goes here.....
Thanks,
enzo c",)
-----Original Message-----
From: Bob Bedell [mailto:bobbedell15@m...]
Sent: Friday, November 29, 2002 1:14 PM
To: Access
Subject: [access] RE: Transaction History
Hi Enzo,
Just a couple of thoughts.
Why would it be necessary to store the SenderID in the Beneficiary
table? Is it possible for a beneficiary to recieve a remittance from
more than one sender? Seems likely. If so, the two entities are linked,
and can be matched, through the Transaction table, which serves as a
junction table.
tblSender tblTranx tblBene
-----------------------------------------
SenderID 1--M SenderID
BeneID M--1 BeneID
SenderID and BeneID would be composite primary keys/foreign keys in the
transaction table, or you could add a TransID field and create a unique
index on the foreign keys.
Second, I can't imagine that storing beneficiary details in the
transactions table would be a necessary or optimal solution. If current
information is obsolete, it seems even more likely that historical
information would be too. But if the historical information is needed,
perhaps the place to put it would be in some type of archive table with
a one-to-one relationship with the beneficiary table. Its hard to
imagine though that it would belong in the transaction table.
Best,
Bob
>From: "Enzo Zaragoza" <enzaux@g...>
>Reply-To: "Access" <access@p...>
>To: "Access" <access@p...>
>Subject: [access] RE: Transaction History
>Date: Fri, 29 Nov 2002 12:53:12 +0800
>
>
> It does matter because sometimes there are it's for back tracking purposes
>for
>example if a person was not reached thru his new telephone number they will
>resort
>checking his old records and get the previous telephone number the
>sender/bene has.
>
>Thanks,
>
>enzo c",)
>
>-----Original Message-----
>From: Haslett, Andrew [mailto:andrew.haslett@i...]
>Sent: Friday, November 29, 2002 11:55 AM
>To: Access
>Subject: [access] RE: Transaction History
>
>
>Why does it matter if sender or beneficiaries details change?
>
>Is it important than an old transaction retain (be linked to) those details
>AT THAT TIME?
>
>If it is, then there's no way around storing their details with every
>transaction.
>
>If not, then it won't matter storing their details once in the senders and
>beneficiaries table.
>
>Think of it this way:
>If you are producing a report listing all transactions, do you want to show
>the sender and beneficiaries details for EVERY transaction, as they were at
>the time of the transaction.. or only once, as they are now...
>
>Cheers,
>A
>
>-----Original Message-----
>From: Enzo Zaragoza [mailto:enzaux@g...]
>Sent: Friday, 29 November 2002 1:10 PM
>To: Access
>Subject: [access] Transaction History
>
>
>
> Hello!!! I would like to have your opinions on my query. Here is
>my situation:
>
> I'm doing a remittance system. I want to know what's the best way
>my
>transaction table
>be set up. I have a Transaction table (tblTranx), Sender Table (tblSender)
>and Benificiaries'
>table (tblBene).
>
>tblTranx tblSender tblBene
>------------------------------------------------
>TranxID
>SenderID M--1 SenderID 1--M SenderID
>BeneID BeneID
> ^M----------------------------------1^
>
> A transaction contains the following:
>1.) Sender & Beneficiary
> - name
> - address
> - tel no
> - cell no
> - other infos
>
>2.) Amount to be remitted
>3.) Other Infos
>
> What I'm concerned with is the Sender and Bene part. What I want
>know is which is better
>to do with the Sender and Bene info, to have only tblTranx.SenderID be
>linked only to
>tblSender.SenderID or to create fields in tblTranx for Sender and Bene
>Infos
>such as name, addr, etc ?
>Taking into considerations that if the Sender and Bene have changes in
>their
>info in the near future.
>
> Currently what I'm doing right now is the second option (created
>fields in tblTranx for Sender
>and Bene Info) because if the sender or bene changes any of its information
>at least the past transactions
>would not be affected since tblTranx has fields that stored the info.
>
> Am I doing the right way? Or are there any better options than
>these? Because with the option I use,
>bloated database is all I have because repeated infos are stored on
>tblTranx. Any tips and suggestions?
>
>Thanks,
>
>
>Enzo c",)
>YahooID: yackydidakdak
>
>
>
>IMPORTANT - PLEASE READ ********************
>This email and any files transmitted with it are confidential and may
>contain information protected by law from disclosure.
>If you have received this message in error, please notify the sender
>immediately and delete this email from your system.
>No warranty is given that this email or files, if attached to this
>email, are free from computer viruses or other defects. They
>are provided on the basis the user assumes all responsibility for
>loss, damage or consequence resulting directly or indirectly from
>their use, whether caused by the negligence of the sender or not.
>
>
>
>
>
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
Message #9 by "Bob Bedell" <bobbedell15@m...> on Fri, 29 Nov 2002 06:12:03 +0000
|
|
Hi Enzo,
Final proposal:) You want the transaction ID number. So...
tblSender tblTranx tblBene tblPhoneNums(opt.)
---------------------------------------------------------------------
TransID(PK) PhoneNumID(PK)
SenderID(PK) 1:M SenderID(FK) ActiveBit
BeneID(FK) M:1 BeneID(PK) 1:M BeneID(FK)
_________________________________________________________________
The new MSN 8: advanced junk mail protection and 2 months FREE*
http://join.msn.com/?page=features/junkmail
Message #10 by "Charlie Goodwin" <cgoodwin@c...> on Fri, 29 Nov 2002 01:44:00 -0500
|
|
Enzo,
I'm not sure it matters but I am curious how senders and benes become conne
cted. Is the sender's relationship to a bene created by a transaction, or
is it created prior to a transaction?
Basically I suspect it is mistaken to store SenderID in TblBene. I think
Bob is asking the right question. If the relationship can be seen in the
TblTranx, by inspecting individual records and noting who gave to who, then
adding that information again elsewhere is entering tha same data repeated
ly.
Everything I have seen on normalization says having the same data entered i
n multiple places is generally a bad idea and a warning that a problem is g
etting designed in. It is inefficient, makes orphaned entries more likely
, and it makes data entry errors more likely.
Charlie
>
> Bene is related only to one Sender or in other words
> a single Sender have many Bene. That's explain why I have the
> Sender ID in the tblBene. Here are the steps during the transaction:
>
> 1.) Select a sender
> 2.) A list of beneficiaries RELATED to Sender is shown
> 3.) Select beneficiary
> 4.) other process goes here.....
>
>
> Thanks,
>
> enzo c",)
>
> -----Original Message-----
> From: Bob Bedell [mailto:bobbedell15@m...] [mailto:bobbedell15@m...
]]
> Sent: Friday, November 29, 2002 1:14 PM
> To: Access
> Subject: [access] RE: Transaction History
>
>
> Hi Enzo,
>
> Just a couple of thoughts.
>
> Why would it be necessary to store the SenderID in the Beneficiary
> table? Is it possible for a beneficiary to recieve a remittance from
> more than one sender? Seems likely. If so, the two entities are linked,
> and can be matched, through the Transaction table, which serves as a
> junction table.
>
> tblSender tblTranx tblBene
> -----------------------------------------
> SenderID 1--M SenderID
> BeneID M--1 BeneID
>
> SenderID and BeneID would be composite primary keys/foreign keys in the
> transaction table, or you could add a TransID field and create a unique
> index on the foreign keys.
>
> Second, I can't imagine that storing beneficiary details in the
> transactions table would be a necessary or optimal solution. If current
> information is obsolete, it seems even more likely that historical
> information would be too. But if the historical information is needed,
> perhaps the place to put it would be in some type of archive table with
> a one-to-one relationship with the beneficiary table. Its hard to
> imagine though that it would belong in the transaction table.
>
> Best,
>
> Bob
>
> >From: "Enzo Zaragoza" <enzaux@g...>
> >Reply-To: "Access" <access@p...>
> >To: "Access" <access@p...>
> >Subject: [access] RE: Transaction History
> >Date: Fri, 29 Nov 2002 12:53:12 +0800
> >
> >
> > It does matter because sometimes there are it's for back tracking purpo
ses
> >for
> >example if a person was not reached thru his new telephone number they w
ill
> >resort
> >checking his old records and get the previous telephone number the
> >sender/bene has.
> >
> >Thanks,
> >
> >enzo c",)
> >
> >-----Original Message-----
> >From: Haslett, Andrew [mailto:andrew.haslett@i...]
> >Sent: Friday, November 29, 2002 11:55 AM
> >To: Access
> >Subject: [access] RE: Transaction History
> >
> >
> >Why does it matter if sender or beneficiaries details change?
> >
> >Is it important than an old transaction retain (be linked to) those deta
ils
> >AT THAT TIME?
> >
> >If it is, then there's no way around storing their details with every
> >transaction.
> >
> >If not, then it won't matter storing their details once in the senders a
nd
> >beneficiaries table.
> >
> >Think of it this way:
> >If you are producing a report listing all transactions, do you want to s
how
> >the sender and beneficiaries details for EVERY transaction, as they were
at
> >the time of the transaction.. or only once, as they are now...
> >
> >Cheers,
> >A
> >
> >-----Original Message-----
> >From: Enzo Zaragoza [mailto:enzaux@g...] [mailto:enzaux@g...]]
> >Sent: Friday, 29 November 2002 1:10 PM
> >To: Access
> >Subject: [access] Transaction History
> >
> >
> >
> > Hello!!! I would like to have your opinions on my query. Here is
> >my situation:
> >
> > I'm doing a remittance system. I want to know what's the best way
> >my
> >transaction table
> >be set up. I have a Transaction table (tblTranx), Sender Table (tblSend
er)
> >and Benificiaries'
> >table (tblBene).
> >
> >tblTranx tblSender tblBene
> >------------------------------------------------
> >TranxID
> >SenderID M--1 SenderID 1--M SenderID
> >BeneID BeneID
> > ^M----------------------------------1^
> >
> > A transaction contains the following:
> >1.) Sender & Beneficiary
> > - name
> > - address
> > - tel no
> > - cell no
> > - other infos
> >
> >2.) Amount to be remitted
> >3.) Other Infos
> >
> > What I'm concerned with is the Sender and Bene part. What I want
> >know is which is better
> >to do with the Sender and Bene info, to have only tblTranx.SenderID be
> >linked only to
> >tblSender.SenderID or to create fields in tblTranx for Sender and Bene
> >Infos
> >such as name, addr, etc ?
> >Taking into considerations that if the Sender and Bene have changes in
> >their
> >info in the near future.
> >
> > Currently what I'm doing right now is the second option (created
> >fields in tblTranx for Sender
> >and Bene Info) because if the sender or bene changes any of its informat
ion
> >at least the past transactions
> >would not be affected since tblTranx has fields that stored the info.
> >
> > Am I doing the right way? Or are there any better options than
> >these? Because with the option I use,
> >bloated database is all I have because repeated infos are stored on
> >tblTranx. Any tips and suggestions?
> >
> >Thanks,
> >
> >
> >Enzo c",)
> >YahooID: yackydidakdak
> >
> >
> >
> >IMPORTANT - PLEASE READ ********************
> >This email and any files transmitted with it are confidential and may
> >contain information protected by law from disclosure.
> >If you have received this message in error, please notify the sender
> >immediately and delete this email from your system.
> >No warranty is given that this email or files, if attached to this
> >email, are free from computer viruses or other defects. They
> >are provided on the basis the user assumes all responsibility for
> >loss, damage or consequence resulting directly or indirectly from
> >their use, whether caused by the negligence of the sender or not.
> >
> >
> >
> >
> >
>
>
> _________________________________________________________________
> Protect your PC - get McAfee.com VirusScan Online
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963
>
>
>
>
>
>
Message #11 by "Enzo Zaragoza" <enzaux@g...> on Fri, 29 Nov 2002 15:19:27 +0800
|
|
Actually the relationship between the sender and the bene is created BEFORE the transaction.
DURING the transaction, all the encoder do is select Sender then after selecting a sender
a list of beneficiares of the sender is shown. No addition of beneficiaries are made during
the transaction, it is a seperate process.
Sorry for not making myself clear.
Thanks,
enzo c",)
-----Original Message-----
From: Charlie Goodwin [mailto:cgoodwin@c...]
Sent: Friday, November 29, 2002 2:44 PM
To: Access
Subject: [access] RE: Transaction History
Enzo,
I'm not sure it matters but I am curious how senders and benes become connected. Is the sender's relationship to a bene created
by a transaction, or is it created prior to a transaction?
Basically I suspect it is mistaken to store SenderID in TblBene. I think Bob is asking the right question. If the relationship
can be seen in the TblTranx, by inspecting individual records and noting who gave to who, then adding that information again
elsewhere is entering tha same data repeatedly.
Everything I have seen on normalization says having the same data entered in multiple places is generally a bad idea and a warning
that a problem is getting designed in. It is inefficient, makes orphaned entries more likely, and it makes data entry errors more
likely.
Charlie
>
> Bene is related only to one Sender or in other words
> a single Sender have many Bene. That's explain why I have the
> Sender ID in the tblBene. Here are the steps during the transaction:
>
> 1.) Select a sender
> 2.) A list of beneficiaries RELATED to Sender is shown
> 3.) Select beneficiary
> 4.) other process goes here.....
>
>
> Thanks,
>
> enzo c",)
>
> -----Original Message-----
> From: Bob Bedell [mailto:bobbedell15@m...] [mailto:bobbedell15@m...]]
> Sent: Friday, November 29, 2002 1:14 PM
> To: Access
> Subject: [access] RE: Transaction History
>
>
> Hi Enzo,
>
> Just a couple of thoughts.
>
> Why would it be necessary to store the SenderID in the Beneficiary
> table? Is it possible for a beneficiary to recieve a remittance from
> more than one sender? Seems likely. If so, the two entities are linked,
> and can be matched, through the Transaction table, which serves as a
> junction table.
>
> tblSender tblTranx tblBene
> -----------------------------------------
> SenderID 1--M SenderID
> BeneID M--1 BeneID
>
> SenderID and BeneID would be composite primary keys/foreign keys in the
> transaction table, or you could add a TransID field and create a unique
> index on the foreign keys.
>
> Second, I can't imagine that storing beneficiary details in the
> transactions table would be a necessary or optimal solution. If current
> information is obsolete, it seems even more likely that historical
> information would be too. But if the historical information is needed,
> perhaps the place to put it would be in some type of archive table with
> a one-to-one relationship with the beneficiary table. Its hard to
> imagine though that it would belong in the transaction table.
>
> Best,
>
> Bob
>
> >From: "Enzo Zaragoza" <enzaux@g...>
> >Reply-To: "Access" <access@p...>
> >To: "Access" <access@p...>
> >Subject: [access] RE: Transaction History
> >Date: Fri, 29 Nov 2002 12:53:12 +0800
> >
> >
> > It does matter because sometimes there are it's for back tracking purposes
> >for
> >example if a person was not reached thru his new telephone number they will
> >resort
> >checking his old records and get the previous telephone number the
> >sender/bene has.
> >
> >Thanks,
> >
> >enzo c",)
> >
> >-----Original Message-----
> >From: Haslett, Andrew [mailto:andrew.haslett@i...]
> >Sent: Friday, November 29, 2002 11:55 AM
> >To: Access
> >Subject: [access] RE: Transaction History
> >
> >
> >Why does it matter if sender or beneficiaries details change?
> >
> >Is it important than an old transaction retain (be linked to) those details
> >AT THAT TIME?
> >
> >If it is, then there's no way around storing their details with every
> >transaction.
> >
> >If not, then it won't matter storing their details once in the senders and
> >beneficiaries table.
> >
> >Think of it this way:
> >If you are producing a report listing all transactions, do you want to show
> >the sender and beneficiaries details for EVERY transaction, as they were at
> >the time of the transaction.. or only once, as they are now...
> >
> >Cheers,
> >A
> >
> >-----Original Message-----
> >From: Enzo Zaragoza [mailto:enzaux@g...] [mailto:enzaux@g...]]
> >Sent: Friday, 29 November 2002 1:10 PM
> >To: Access
> >Subject: [access] Transaction History
> >
> >
> >
> > Hello!!! I would like to have your opinions on my query. Here is
> >my situation:
> >
> > I'm doing a remittance system. I want to know what's the best way
> >my
> >transaction table
> >be set up. I have a Transaction table (tblTranx), Sender Table (tblSender)
> >and Benificiaries'
> >table (tblBene).
> >
> >tblTranx tblSender tblBene
> >------------------------------------------------
> >TranxID
> >SenderID M--1 SenderID 1--M SenderID
> >BeneID BeneID
> > ^M----------------------------------1^
> >
> > A transaction contains the following:
> >1.) Sender & Beneficiary
> > - name
> > - address
> > - tel no
> > - cell no
> > - other infos
> >
> >2.) Amount to be remitted
> >3.) Other Infos
> >
> > What I'm concerned with is the Sender and Bene part. What I want
> >know is which is better
> >to do with the Sender and Bene info, to have only tblTranx.SenderID be
> >linked only to
> >tblSender.SenderID or to create fields in tblTranx for Sender and Bene
> >Infos
> >such as name, addr, etc ?
> >Taking into considerations that if the Sender and Bene have changes in
> >their
> >info in the near future.
> >
> > Currently what I'm doing right now is the second option (created
> >fields in tblTranx for Sender
> >and Bene Info) because if the sender or bene changes any of its information
> >at least the past transactions
> >would not be affected since tblTranx has fields that stored the info.
> >
> > Am I doing the right way? Or are there any better options than
> >these? Because with the option I use,
> >bloated database is all I have because repeated infos are stored on
> >tblTranx. Any tips and suggestions?
> >
> >Thanks,
> >
> >
> >Enzo c",)
> >YahooID: yackydidakdak
> >
> >
> >
> >IMPORTANT - PLEASE READ ********************
> >This email and any files transmitted with it are confidential and may
> >contain information protected by law from disclosure.
> >If you have received this message in error, please notify the sender
> >immediately and delete this email from your system.
> >No warranty is given that this email or files, if attached to this
> >email, are free from computer viruses or other defects. They
> >are provided on the basis the user assumes all responsibility for
> >loss, damage or consequence resulting directly or indirectly from
> >their use, whether caused by the negligence of the sender or not.
> >
> >
> >
> >
> >
>
>
> _________________________________________________________________
> Protect your PC - get McAfee.com VirusScan Online
> http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
>
>
>
>
>
>
Message #12 by "Charlie Goodwin" <cgoodwin@c...> on Fri, 29 Nov 2002 11:51:27 -0500
|
|
Hiya,
If the relationship between a given sender and a few beneficiaries is set
ahead of time and is relatively durable - howzabout this:
A table of people, TblPeople:
PeopleID AutoNumber
names Text
addresses Text
phones Text
etc.
A table TblSenderBeneMatch matching Senders to their Beneficiaries:
SenderBeneMatchId AutoNumber
SenderID Number related to TblPeople
BeneID Number related to TblPeople
A table for transactions:
TranxID AutoNumber
SenderBeneMatchID Number related to TblSenderBeneMatch
Date Date/Time
MoneyAmount Number
This allows you to encode who is connected to who - in one place only.
This allows you to enter items like name address etc - in one place only.
Reduces bloat dramatically.
It would be easy to create a form for transaction data entry that fits the
process you describe: select sender first, then choose from sender's
list of Beneficiaries.
It makes relationship of sender to beneficiary clear and simple.
Let me know if this makes sense,
Charlie
> Actually the relationship between the sender and the bene is created BEFO
RE the transaction.
> DURING the transaction, all the encoder do is select Sender then after se
lecting a sender
> a list of beneficiares of the sender is shown. No addition of beneficiar
ies are made during
> the transaction, it is a seperate process.
>
> Sorry for not making myself clear.
>
> Thanks,
>
> enzo c",)
>
> -----Original Message-----
> From: Charlie Goodwin [mailto:cgoodwin@c...] [mailto:cgoodwin@c...
net.com]]
> Sent: Friday, November 29, 2002 2:44 PM
> To: Access
> Subject: [access] RE: Transaction History
>
>
> Enzo,
>
> I'm not sure it matters but I am curious how senders and benes become con
nected. Is the sender's relationship to a bene created
> by a transaction, or is it created prior to a transaction?
>
> Basically I suspect it is mistaken to store SenderID in TblBene. I thin
k Bob is asking the right question. If the relationship
> can be seen in the TblTranx, by inspecting individual records and noting
who gave to who, then adding that information again
> elsewhere is entering tha same data repeatedly.
>
> Everything I have seen on normalization says having the same data entered
in multiple places is generally a bad idea and a warning
> that a problem is getting designed in. It is inefficient, makes orphane
d entries more likely, and it makes data entry errors more
> likely.
>
> Charlie
>
>
>
>
>
> >
> > Bene is related only to one Sender or in other words
> > a single Sender have many Bene. That's explain why I have the
> > Sender ID in the tblBene. Here are the steps during the transaction:
> >
> > 1.) Select a sender
> > 2.) A list of beneficiaries RELATED to Sender is shown
> > 3.) Select beneficiary
> > 4.) other process goes here.....
> >
> >
> > Thanks,
> >
> > enzo c",)
> >
> > -----Original Message-----
> > From: Bob Bedell [mailto:bobbedell15@m...] [mailto:bobbedell15@m...
om]] [mailto:bobbedell15@m...]] [mailto:bobbedell15@m...]]]
> > Sent: Friday, November 29, 2002 1:14 PM
> > To: Access
> > Subject: [access] RE: Transaction History
> >
> >
> > Hi Enzo,
> >
> > Just a couple of thoughts.
> >
> > Why would it be necessary to store the SenderID in the Beneficiary
> > table? Is it possible for a beneficiary to recieve a remittance from
> > more than one sender? Seems likely. If so, the two entities are linked,
> > and can be matched, through the Transaction table, which serves as a
> > junction table.
> >
> > tblSender tblTranx tblBene
> > -----------------------------------------
> > SenderID 1--M SenderID
> > BeneID M--1 BeneID
> >
> > SenderID and BeneID would be composite primary keys/foreign keys in the
> > transaction table, or you could add a TransID field and create a unique
> > index on the foreign keys.
> >
> > Second, I can't imagine that storing beneficiary details in the
> > transactions table would be a necessary or optimal solution. If current
> > information is obsolete, it seems even more likely that historical
> > information would be too. But if the historical information is needed,
> > perhaps the place to put it would be in some type of archive table with
> > a one-to-one relationship with the beneficiary table. Its hard to
> > imagine though that it would belong in the transaction table.
> >
> > Best,
> >
> > Bob
> >
> > >From: "Enzo Zaragoza" <enzaux@g...>
> > >Reply-To: "Access" <access@p...>
> > >To: "Access" <access@p...>
> > >Subject: [access] RE: Transaction History
> > >Date: Fri, 29 Nov 2002 12:53:12 +0800
> > >
> > >
> > > It does matter because sometimes there are it's for back tracking pur
poses
> > >for
> > >example if a person was not reached thru his new telephone number they
will
> > >resort
> > >checking his old records and get the previous telephone number the
> > >sender/bene has.
> > >
> > >Thanks,
> > >
> > >enzo c",)
> > >
> > >-----Original Message-----
> > >From: Haslett, Andrew [mailto:andrew.haslett@i...]
> > >Sent: Friday, November 29, 2002 11:55 AM
> > >To: Access
> > >Subject: [access] RE: Transaction History
> > >
> > >
> > >Why does it matter if sender or beneficiaries details change?
> > >
> > >Is it important than an old transaction retain (be linked to) those de
tails
> > >AT THAT TIME?
> > >
> > >If it is, then there's no way around storing their details with every
> > >transaction.
> > >
> > >If not, then it won't matter storing their details once in the senders
and
> > >beneficiaries table.
> > >
> > >Think of it this way:
> > >If you are producing a report listing all transactions, do you want to
show
> > >the sender and beneficiaries details for EVERY transaction, as they we
re at
> > >the time of the transaction.. or only once, as they are now...
> > >
> > >Cheers,
> > >A
> > >
> > >-----Original Message-----
> > >From: Enzo Zaragoza [mailto:enzaux@g...] [mailto:enzaux@g...]] [
mailto:enzaux@g...]] [mailto:enzaux@g...]]]
> > >Sent: Friday, 29 November 2002 1:10 PM
> > >To: Access
> > >Subject: [access] Transaction History
> > >
> > >
> > >
> > > Hello!!! I would like to have your opinions on my query. Here is
> > >my situation:
> > >
> > > I'm doing a remittance system. I want to know what's the best
way
> > >my
> > >transaction table
> > >be set up. I have a Transaction table (tblTranx), Sender Table (tblSe
nder)
> > >and Benificiaries'
> > >table (tblBene).
> > >
> > >tblTranx tblSender tblBene
> > >------------------------------------------------
> > >TranxID
> > >SenderID M--1 SenderID 1--M SenderID
> > >BeneID BeneID
> > > ^M----------------------------------1^
> > >
> > > A transaction contains the following:
> > >1.) Sender & Beneficiary
> > > - name
> > > - address
> > > - tel no
> > > - cell no
> > > - other infos
> > >
> > >2.) Amount to be remitted
> > >3.) Other Infos
> > >
> > > What I'm concerned with is the Sender and Bene part. What I want
> > >know is which is better
> > >to do with the Sender and Bene info, to have only tblTranx.SenderID be
> > >linked only to
> > >tblSender.SenderID or to create fields in tblTranx for Sender and Bene
> > >Infos
> > >such as name, addr, etc ?
> > >Taking into considerations that if the Sender and Bene have changes in
> > >their
> > >info in the near future.
> > >
> > > Currently what I'm doing right now is the second option (created
> > >fields in tblTranx for Sender
> > >and Bene Info) because if the sender or bene changes any of its inform
ation
> > >at least the past transactions
> > >would not be affected since tblTranx has fields that stored the info.
> > >
> > > Am I doing the right way? Or are there any better options than
> > >these? Because with the option I use,
> > >bloated database is all I have because repeated infos are stored on
> > >tblTranx. Any tips and suggestions?
> > >
> > >Thanks,
> > >
> > >
> > >Enzo c",)
> > >YahooID: yackydidakdak
> > >
> > >
> > >
> > >IMPORTANT - PLEASE READ ********************
> > >This email and any files transmitted with it are confidential and may
> > >contain information protected by law from disclosure.
> > >If you have received this message in error, please notify the sender
> > >immediately and delete this email from your system.
> > >No warranty is given that this email or files, if attached to this
> > >email, are free from computer viruses or other defects. They
> > >are provided on the basis the user assumes all responsibility for
> > >loss, damage or consequence resulting directly or indirectly from
> > >their use, whether caused by the negligence of the sender or not.
> > >
> > >
> > >
> > >
> > >
> >
> >
> > _________________________________________________________________
> > Protect your PC - get McAfee.com VirusScan Online
> > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3D3963
> >
> >
> >
> >
> >
> >
>
>
>
>
>
Message #13 by "Enzo Zaragoza" <enzaux@g...> on Sat, 30 Nov 2002 15:30:35 +0800
|
|
Thanks for input guys! Andrew, Bob and Charlie ;)
Thanks,
enzo c",)
-----Original Message-----
From: Charlie Goodwin [mailto:cgoodwin@c...]
Sent: Saturday, November 30, 2002 12:51 AM
To: Access
Subject: [access] RE: Transaction History
Hiya,
If the relationship between a given sender and a few beneficiaries is set
ahead of time and is relatively durable - howzabout this:
A table of people, TblPeople:
PeopleID AutoNumber
names Text
addresses Text
phones Text
etc.
A table TblSenderBeneMatch matching Senders to their Beneficiaries:
SenderBeneMatchId AutoNumber
SenderID Number related to TblPeople
BeneID Number related to TblPeople
A table for transactions:
TranxID AutoNumber
SenderBeneMatchID Number related to TblSenderBeneMatch
Date Date/Time
MoneyAmount Number
This allows you to encode who is connected to who - in one place only.
This allows you to enter items like name address etc - in one place only.
Reduces bloat dramatically.
It would be easy to create a form for transaction data entry that fits the
process you describe: select sender first, then choose from sender's
list of Beneficiaries.
It makes relationship of sender to beneficiary clear and simple.
Let me know if this makes sense,
Charlie
> Actually the relationship between the sender and the bene is created BEFORE the transaction.
> DURING the transaction, all the encoder do is select Sender then after selecting a sender
> a list of beneficiares of the sender is shown. No addition of beneficiaries are made during
> the transaction, it is a seperate process.
>
> Sorry for not making myself clear.
>
> Thanks,
>
> enzo c",)
>
> -----Original Message-----
> From: Charlie Goodwin [mailto:cgoodwin@c...] [mailto:cgoodwin@c...]]
> Sent: Friday, November 29, 2002 2:44 PM
> To: Access
> Subject: [access] RE: Transaction History
>
>
> Enzo,
>
> I'm not sure it matters but I am curious how senders and benes become connected. Is the sender's relationship to a bene
created
> by a transaction, or is it created prior to a transaction?
>
> Basically I suspect it is mistaken to store SenderID in TblBene. I think Bob is asking the right question. If the
relationship
> can be seen in the TblTranx, by inspecting individual records and noting who gave to who, then adding that information again
> elsewhere is entering tha same data repeatedly.
>
> Everything I have seen on normalization says having the same data entered in multiple places is generally a bad idea and a
warning
> that a problem is getting designed in. It is inefficient, makes orphaned entries more likely, and it makes data entry errors
more
> likely.
>
> Charlie
>
>
>
>
>
> >
> > Bene is related only to one Sender or in other words
> > a single Sender have many Bene. That's explain why I have the
> > Sender ID in the tblBene. Here are the steps during the transaction:
> >
> > 1.) Select a sender
> > 2.) A list of beneficiaries RELATED to Sender is shown
> > 3.) Select beneficiary
> > 4.) other process goes here.....
> >
> >
> > Thanks,
> >
> > enzo c",)
> >
> > -----Original Message-----
> > From: Bob Bedell [mailto:bobbedell15@m...] [mailto:bobbedell15@m...]] [mailto:bobbedell15@m...]]
[mailto:bobbedell15@m...]]]
> > Sent: Friday, November 29, 2002 1:14 PM
> > To: Access
> > Subject: [access] RE: Transaction History
> >
> >
> > Hi Enzo,
> >
> > Just a couple of thoughts.
> >
> > Why would it be necessary to store the SenderID in the Beneficiary
> > table? Is it possible for a beneficiary to recieve a remittance from
> > more than one sender? Seems likely. If so, the two entities are linked,
> > and can be matched, through the Transaction table, which serves as a
> > junction table.
> >
> > tblSender tblTranx tblBene
> > -----------------------------------------
> > SenderID 1--M SenderID
> > BeneID M--1 BeneID
> >
> > SenderID and BeneID would be composite primary keys/foreign keys in the
> > transaction table, or you could add a TransID field and create a unique
> > index on the foreign keys.
> >
> > Second, I can't imagine that storing beneficiary details in the
> > transactions table would be a necessary or optimal solution. If current
> > information is obsolete, it seems even more likely that historical
> > information would be too. But if the historical information is needed,
> > perhaps the place to put it would be in some type of archive table with
> > a one-to-one relationship with the beneficiary table. Its hard to
> > imagine though that it would belong in the transaction table.
> >
> > Best,
> >
> > Bob
> >
> > >From: "Enzo Zaragoza" <enzaux@g...>
> > >Reply-To: "Access" <access@p...>
> > >To: "Access" <access@p...>
> > >Subject: [access] RE: Transaction History
> > >Date: Fri, 29 Nov 2002 12:53:12 +0800
> > >
> > >
> > > It does matter because sometimes there are it's for back tracking purposes
> > >for
> > >example if a person was not reached thru his new telephone number they will
> > >resort
> > >checking his old records and get the previous telephone number the
> > >sender/bene has.
> > >
> > >Thanks,
> > >
> > >enzo c",)
> > >
> > >-----Original Message-----
> > >From: Haslett, Andrew [mailto:andrew.haslett@i...]
> > >Sent: Friday, November 29, 2002 11:55 AM
> > >To: Access
> > >Subject: [access] RE: Transaction History
> > >
> > >
> > >Why does it matter if sender or beneficiaries details change?
> > >
> > >Is it important than an old transaction retain (be linked to) those details
> > >AT THAT TIME?
> > >
> > >If it is, then there's no way around storing their details with every
> > >transaction.
> > >
> > >If not, then it won't matter storing their details once in the senders and
> > >beneficiaries table.
> > >
> > >Think of it this way:
> > >If you are producing a report listing all transactions, do you want to show
> > >the sender and beneficiaries details for EVERY transaction, as they were at
> > >the time of the transaction.. or only once, as they are now...
> > >
> > >Cheers,
> > >A
> > >
> > >-----Original Message-----
> > >From: Enzo Zaragoza [mailto:enzaux@g...] [mailto:enzaux@g...]] [mailto:enzaux@g...]]
[mailto:enzaux@g...]]]
> > >Sent: Friday, 29 November 2002 1:10 PM
> > >To: Access
> > >Subject: [access] Transaction History
> > >
> > >
> > >
> > > Hello!!! I would like to have your opinions on my query. Here is
> > >my situation:
> > >
> > > I'm doing a remittance system. I want to know what's the best way
> > >my
> > >transaction table
> > >be set up. I have a Transaction table (tblTranx), Sender Table (tblSender)
> > >and Benificiaries'
> > >table (tblBene).
> > >
> > >tblTranx tblSender tblBene
> > >------------------------------------------------
> > >TranxID
> > >SenderID M--1 SenderID 1--M SenderID
> > >BeneID BeneID
> > > ^M----------------------------------1^
> > >
> > > A transaction contains the following:
> > >1.) Sender & Beneficiary
> > > - name
> > > - address
> > > - tel no
> > > - cell no
> > > - other infos
> > >
> > >2.) Amount to be remitted
> > >3.) Other Infos
> > >
> > > What I'm concerned with is the Sender and Bene part. What I want
> > >know is which is better
> > >to do with the Sender and Bene info, to have only tblTranx.SenderID be
> > >linked only to
> > >tblSender.SenderID or to create fields in tblTranx for Sender and Bene
> > >Infos
> > >such as name, addr, etc ?
> > >Taking into considerations that if the Sender and Bene have changes in
> > >their
> > >info in the near future.
> > >
> > > Currently what I'm doing right now is the second option (created
> > >fields in tblTranx for Sender
> > >and Bene Info) because if the sender or bene changes any of its information
> > >at least the past transactions
> > >would not be affected since tblTranx has fields that stored the info.
> > >
> > > Am I doing the right way? Or are there any better options than
> > >these? Because with the option I use,
> > >bloated database is all I have because repeated infos are stored on
> > >tblTranx. Any tips and suggestions?
> > >
> > >Thanks,
> > >
> > >
> > >Enzo c",)
> > >YahooID: yackydidakdak
> > >
> > >
> > >
> > >IMPORTANT - PLEASE READ ********************
> > >This email and any files transmitted with it are confidential and may
> > >contain information protected by law from disclosure.
> > >If you have received this message in error, please notify the sender
> > >immediately and delete this email from your system.
> > >No warranty is given that this email or files, if attached to this
> > >email, are free from computer viruses or other defects. They
> > >are provided on the basis the user assumes all responsibility for
> > >loss, damage or consequence resulting directly or indirectly from
> > >their use, whether caused by the negligence of the sender or not.
> > >
> > >
> > >
> > >
> > >
> >
> >
> > _________________________________________________________________
> > Protect your PC - get McAfee.com VirusScan Online
> > http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> >
> >
> >
> >
> >
> >
>
>
>
>
>
|
|
|
View Cart
