John,
In my mind I was afraid you were going to say that. Now I am going to have to move around a lot of info. I think I will create one new table with the common info and then modify the old tables. … and then rewrite my queries.
Thanks,
Bill
From: MS_Access_Professionals@yahoogroups.com [mailto:MS_Access_Professionals@yahoogroups.com] On Behalf Of John Viescas
Sent: Wednesday, February 12, 2014 11:06 AM
To: MS_Access_Professionals@yahoogroups.com
Subject: Re: [MS_AccessPros] One table or many?
Bill-
Consider building a single "Insurance" table with the 6 common fields and a field that indicates the policy type. Then build a table for each policy subtype that contains the fields relevant to that type. Do a 1-1 relationship on PolicyID from the main insurance table to each of the sub-tables. As for a form to edit this stuff, use a main form for the main Insurance table and a subform that you dynamically load to edit the correct sub-table based on policy type.
John Viescas, Author
Microsoft Access 2010 Inside Out
Microsoft Access 2007 Inside Out
Microsoft Access 2003 Inside Out
Building Microsoft Access Applications
SQL Queries for Mere Mortals
(Paris, France)
Balmy 9 degrees - Centigrade!
On Feb 12, 2014, at 4:13 PM, Bill Singer <Bill.Singer@at-group.net> wrote:
I have a database that tracks insurance policies for companies.
I have separate tables for Health insurance , life insurance, Disabilty …etc.
Most policies have different items that need to be tracked so the tables look different, with the exception of about 6 fields. All policies have about 6 or so thing in common.
Should I combine all this info into one table or should I keep the tables separate. The table would become rather large in my mind (35 fields) but I would only have one table.
What is the best way to do this.
Thanks for the comments.
Bill
MN
Balmy 18 degrees
| Reply via web post | Reply to sender | Reply to group | Start a New Topic | Messages in this topic (3) |
Tidak ada komentar:
Posting Komentar