If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Design help
Hi folks,
I have to design a table or tables to contain the following type of info: OrgNbr OrgName SubOrg1 SubOrg2 SubOrg3 SubOrg4 SubOrg5 Each Org can have multiple SubOrgs so I would end up with the same Info being repeated in some of the fields. I though that if I broke the table down into: OrgNbr OrgNbr SubOrg1 SubOrg2 OrgName SubOrg1 SubOrg2 SubOrg3... I would at least alleviate some of the redundancy. Now my question - for anyone who has managed to follow thus far is this. I have to associate a client with an Org, but do I really have to store all of the Org and SubOrg numbers with the client or is their another way? Right now we have each client associated with an Org, but we want to break down the Org into these separate pieces and then associate the client with that. Can I get away with storing just one number or do I have to associate all SubOrgs and the Org with the Client? Any ideas are appreciated. C |
#2
|
|||
|
|||
Design help
You should break that out into 2 tables.
tblOrganizations OrgNbr (Primary Key) OrgName ....Other fields releated to an Organization tblSubOrganizations SubOrgNbr (Primary Key) OrgNbr ....Other Fields related to a Sub Organization Now you can create as few or as many SubOrgs as you need for each Organization. -- Lynn Trapp MS Access MVP www.ltcomputerdesigns.com Access Security: www.ltcomputerdesigns.com/Security.htm "C. Walters" wrote in message ... Hi folks, I have to design a table or tables to contain the following type of info: OrgNbr OrgName SubOrg1 SubOrg2 SubOrg3 SubOrg4 SubOrg5 Each Org can have multiple SubOrgs so I would end up with the same Info being repeated in some of the fields. I though that if I broke the table down into: OrgNbr OrgNbr SubOrg1 SubOrg2 OrgName SubOrg1 SubOrg2 SubOrg3... I would at least alleviate some of the redundancy. Now my question - for anyone who has managed to follow thus far is this. I have to associate a client with an Org, but do I really have to store all of the Org and SubOrg numbers with the client or is their another way? Right now we have each client associated with an Org, but we want to break down the Org into these separate pieces and then associate the client with that. Can I get away with storing just one number or do I have to associate all SubOrgs and the Org with the Client? Any ideas are appreciated. C |
#3
|
|||
|
|||
Design help
Yes, I am doing that. Now, how do I relate that back to
a client? Suppose I have 2 clients, 1 is associated with Org 1, the other is associated with Org1, SubOrg1. Which Org/SubOrg number do I store with the client? All? -----Original Message----- You should break that out into 2 tables. tblOrganizations OrgNbr (Primary Key) OrgName ....Other fields releated to an Organization tblSubOrganizations SubOrgNbr (Primary Key) OrgNbr ....Other Fields related to a Sub Organization Now you can create as few or as many SubOrgs as you need for each Organization. -- Lynn Trapp MS Access MVP www.ltcomputerdesigns.com Access Security: www.ltcomputerdesigns.com/Security.htm "C. Walters" wrote in message ... Hi folks, I have to design a table or tables to contain the following type of info: OrgNbr OrgName SubOrg1 SubOrg2 SubOrg3 SubOrg4 SubOrg5 Each Org can have multiple SubOrgs so I would end up with the same Info being repeated in some of the fields. I though that if I broke the table down into: OrgNbr OrgNbr SubOrg1 SubOrg2 OrgName SubOrg1 SubOrg2 SubOrg3... I would at least alleviate some of the redundancy. Now my question - for anyone who has managed to follow thus far is this. I have to associate a client with an Org, but do I really have to store all of the Org and SubOrg numbers with the client or is their another way? Right now we have each client associated with an Org, but we want to break down the Org into these separate pieces and then associate the client with that. Can I get away with storing just one number or do I have to associate all SubOrgs and the Org with the Client? Any ideas are appreciated. C . |
#4
|
|||
|
|||
Design help
That depends entirely on your design and your business needs. Ask yourself
some questions and it will probably lead you to the answer. 1. Can a given Organization have more than one Client? 2. Can a given Sub Organization have more than one Client? If an Organization can have more than one Client AND a Sub Organization can have more than one client, then you will probably want to have your third table related to the Sub Organization table. If an Organization can have only one Client and, therefore, a Sub Organization can have only one client, then you can relate it to the Organization table. -- Lynn Trapp MS Access MVP www.ltcomputerdesigns.com Access Security: www.ltcomputerdesigns.com/Security.htm "C. Walters" wrote in message ... Yes, I am doing that. Now, how do I relate that back to a client? Suppose I have 2 clients, 1 is associated with Org 1, the other is associated with Org1, SubOrg1. Which Org/SubOrg number do I store with the client? All? -----Original Message----- You should break that out into 2 tables. tblOrganizations OrgNbr (Primary Key) OrgName ....Other fields releated to an Organization tblSubOrganizations SubOrgNbr (Primary Key) OrgNbr ....Other Fields related to a Sub Organization Now you can create as few or as many SubOrgs as you need for each Organization. -- Lynn Trapp MS Access MVP www.ltcomputerdesigns.com Access Security: www.ltcomputerdesigns.com/Security.htm "C. Walters" wrote in message ... Hi folks, I have to design a table or tables to contain the following type of info: OrgNbr OrgName SubOrg1 SubOrg2 SubOrg3 SubOrg4 SubOrg5 Each Org can have multiple SubOrgs so I would end up with the same Info being repeated in some of the fields. I though that if I broke the table down into: OrgNbr OrgNbr SubOrg1 SubOrg2 OrgName SubOrg1 SubOrg2 SubOrg3... I would at least alleviate some of the redundancy. Now my question - for anyone who has managed to follow thus far is this. I have to associate a client with an Org, but do I really have to store all of the Org and SubOrg numbers with the client or is their another way? Right now we have each client associated with an Org, but we want to break down the Org into these separate pieces and then associate the client with that. Can I get away with storing just one number or do I have to associate all SubOrgs and the Org with the Client? Any ideas are appreciated. C . |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Document Starts in Design Mode every time I open it | Colin Higbie | General Discussion | 4 | June 14th, 2004 12:24 PM |
finding design examples for Invoices and Payments | Paul James | Database Design | 2 | June 9th, 2004 07:14 PM |
Applying a Custom Design Template | Clyde | Powerpoint | 1 | June 7th, 2004 09:47 PM |
Printing a Theme Design | Andrew | General Discussion | 1 | May 28th, 2004 01:00 AM |
opening a document so it is NOT in design mode | Brad Pears | New Users | 1 | May 3rd, 2004 09:13 PM |