[mso] Re: Sorry Very Long Setting up DB ... Naming and Relations Access 2K :VSMail mx3
- From: James LaBorde <jlaborde@xxxxxxxxx>
- To: "'mso@xxxxxxxxxxxxx'" <mso@xxxxxxxxxxxxx>
- Date: Tue, 31 Dec 2002 12:37:05 -0800
April,
You will want to separate the data that will duplicate. Doctors will likely
be their own table since they may have more than one patient. Any data that
is particular to the doctor will go in their table and a fk will be in the
client table listing which doctor they have. Remember, the particular data
has to relate directly to the primary key. Will the patient see more than
one doctor? You may want a visits table that would be separate from all of
the others. You still want your separate tables if the data will not refer
uniquely to the primary key. The additional tables you have with billing
and mailing addresses could go either way. Insurance carriers again will
duplicate across clients and will likely have data of their own. It would
work to have a table for them and a single reference to it in your client
table.
I was merely trying to point out the fact that you can have a large number
of fields in a table that refer specifically to the primary key. We have a
number of tables in our operational database that have over 100 fields per
record.
In your question you list separate entities in each question. That data is
important but if you have data specific to those separate entities you will
want to separate them. That way you only have one listing for each
insurance carrier and have minimal problems of misspellings or typos in the
address. Think of all the fields you need to include and ask yourself what
the field refers to. If it refers to the primary key, then it belongs in
the table, if it refers to another field in your table, it should probably
be its own table with a foreign key designated for it. In your Insurance
carriers example, insurance carrier refers to the primary key of patient,
but insurance carrier address refers to insurance carrier. So you would
include an Insurance Carriers table and have a field in your patients table
that referred to the specific insurance carrier.
I hope I am helping with clearing this up, rather than making the waters
muddier.
James
-----Original Message-----
From: 4office [mailto:4office@xxxxxxxxxxxxx]
Sent: Tuesday, December 31, 2002 11:41 AM
To: mso@xxxxxxxxxxxxx
Subject: [mso] Re: Sorry Very Long Setting up DB ... Naming and
Relations Access 2K :VSMail mx3
James,
Ok then are you saying that it is ok to put ALL the information that I have
broken up on the 7 tables that I listed before (and the approx 5 that I did
not spell out) into ONE table, since they are all information related to the
"Client" : Who are they, who will pay, who is their doctor, who is their
insurance carrier....
April
-----Original Message-----
From: mso-bounce@xxxxxxxxxxxxx [mailto:mso-bounce@xxxxxxxxxxxxx]On
Behalf Of James LaBorde
Sent: Tuesday, December 31, 2002 2:07 PM
To: 'mso@xxxxxxxxxxxxx'
Subject: [mso] Re: Sorry Very Long Setting up DB ... Naming and
Relations Access 2K :VSMail mx3
40ffice (sorry, you didn't use your name),
The easy answer to your question is that the limit to the number of columns
in a single table is only limited by size. The best way to determine if you
should break up your tables is to ask yourself if everything in the table
refers to the Primary Key. In the case of your first table, that would be
the client. One thing to remember about your look-ups, don't embed the
data. Make a small table that houses the data and make sure that somewhere
in your application you give a user (an Admin) the ability to add to that
list if necessary. You are correct about the age being able to be
calculated. There are some issues with calculating age though so be
careful. You can make it display in any format you choose, although it may
require that you do a little coding to get the exact format you wish.
As far as your redundancy issues. You can leave certain fields inactive and
unaccessible until the appropriate box is checked. You are venturing into
territory where you will need the vba coding more and more though.
I hope this helps. If you have any more specific questions feel free to
ask.
One resource that should be of great help will be
http://www.mvps.org/access/
James
*************************************************************
You are receiving this mail because you subscribed to mso@xxxxxxxxxxxxx or
MicrosoftOffice@xxxxxxxxxxxxxxxx
To send mail to the group, simply address it to mso@xxxxxxxxxxxxx
To Unsubscribe from this group, send an email to
mso-request@xxxxxxxxxxxxx?Subject=unsubscribe
Or, visit the group's homepage and use the dropdown menu. This will also
allow you to change your email settings to digest or vacation (no mail).
//www.freelists.org/webpage/mso
To be able to use the files section for sharing files with the group, send a
request to mso-moderators@xxxxxxxxxxxxx and you will be sent an invitation
with instructions. Once you are a member of the files group, you can go
here to upload/download files:
http://www.smartgroups.com/vault/msofiles
*************************************************************
*************************************************************
You are receiving this mail because you subscribed to mso@xxxxxxxxxxxxx or
MicrosoftOffice@xxxxxxxxxxxxxxxx
To send mail to the group, simply address it to mso@xxxxxxxxxxxxx
To Unsubscribe from this group, send an email to
mso-request@xxxxxxxxxxxxx?Subject=unsubscribe
Or, visit the group's homepage and use the dropdown menu. This will also allow
you to change your email settings to digest or vacation (no mail).
//www.freelists.org/webpage/mso
To be able to use the files section for sharing files with the group, send a
request to mso-moderators@xxxxxxxxxxxxx and you will be sent an invitation with
instructions. Once you are a member of the files group, you can go here to
upload/download files:
http://www.smartgroups.com/vault/msofiles
*************************************************************
Other related posts:
