Having one table with all the common info will make the summary form a lot easier to develop. On the summary form for each client I want to have the common information listed for each line of coverage. It will be much easier to pull from one table. If I have separate tables I will have to use a UNION query and then I believe I will not be able to edit the information on the summary form because I do not believe I can edit information in a union query, although I have not tested it.
Your way would be the best way. It will be harder to do in the short team but it will be easier to find and edit data in the long term.
Thanks for the tips.
Bill
From: MS_Access_Professionals@yahoogroups.com [mailto:MS_Access_Professionals@yahoogroups.com] On Behalf Of John Viescas
Sent: Wednesday, February 12, 2014 11:53 AM
To: MS_Access_Professionals@yahoogroups.com
Subject: Re: [MS_AccessPros] One table or many?
Bill-
There's nothing wrong with multiple tables - one per each policy type. I was just explaining how *I* would have done it.
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)
On Feb 12, 2014, at 6:26 PM, Bill Singer <Bill.Singer@at-group.net> wrote:
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 (5) |
Tidak ada komentar:
Posting Komentar