RE: Sufficient reason to de-normalize a field?
From: Kevin Yu [MSFT] (v-kevy_at_online.microsoft.com)
Date: 06/15/04
- Next message: Venkat: "Re: Backup and restore feature on VB6 application"
- Previous message: Earl: "Sufficient reason to de-normalize a field?"
- In reply to: Earl: "Sufficient reason to de-normalize a field?"
- Next in thread: Earl: "Re: Sufficient reason to de-normalize a field?"
- Reply: Earl: "Re: Sufficient reason to de-normalize a field?"
- Messages sorted by: [ date ] [ thread ]
Date: Tue, 15 Jun 2004 09:31:00 GMT
Hi Earl,
First of all, I would like to confirm my understanding of your issue. From
your description, I understand that you need to know how to design the
database structure without redundant data in a senario that payee is
automatically added into database. If there is any misunderstanding, please
feel free to let me know.
Based on my experience, you can also keep your database from redundant data
in this case. When adding payee to the database table, we can first check
for existence in the subordinate table to see if this name has been added.
If it hasn't been added, add it. The insert procedure returns the ID for
the payee. Then we use this ID to update the payee's ID in the main table
and insert the payment transaction into database.
HTH. If anything is unclear, please feel free to reply to the post.
Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."
- Next message: Venkat: "Re: Backup and restore feature on VB6 application"
- Previous message: Earl: "Sufficient reason to de-normalize a field?"
- In reply to: Earl: "Sufficient reason to de-normalize a field?"
- Next in thread: Earl: "Re: Sufficient reason to de-normalize a field?"
- Reply: Earl: "Re: Sufficient reason to de-normalize a field?"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|