Hi,
I'm trying to create a simple database for info for dance class students
that includes mailing addresses and class info. Most are children, so I
need the parent names. A few parents have two or three children in a dance
class. Some students are adults. I think I need a parents table AND a
students table otherwise I'm entering duplicate information (addresses etc.)

Two students are also instructors but I think I can use a Yes.No field for
this. I can't get my head around how I link them.

What comes first, the parent table or the students table. Most are children
if that makes a difference.

Any help is appreciated.

Nancy

The parent table would be first. I'd assign a unique code to each
parent, then create a "Parent Code" field in the student's table to
which I'd link.

Just my thoughts...
Rita

Nan wrote:
> Hi,
> I'm trying to create a simple database for info for dance class students
> that includes mailing addresses and class info. Most are children, so I
> need the parent names. A few parents have two or three children in a dance
> class. Some students are adults. I think I need a parents table AND a
> students table otherwise I'm entering duplicate information (addresses etc.)
>
> Two students are also instructors but I think I can use a Yes.No field for
> this. I can't get my head around how I link them.
>
> What comes first, the parent table or the students table. Most are children
> if that makes a difference.
>
> Any help is appreciated.
>
> Nancy
>
>

Rita, Thanks.
I began to do that but then hit a snag on how to handle the adults who are
students and students who are adults. Also, how to record adult students
who have children in a dance class. There are two right now. I want to
record mailing information only once and send it only to the parent or adult
student. I have to give it a lot more thought. I think I'm getting hung up
on calling it a parents table when it really is an adults table.

Could you or anyone direct me to a help site on this or a good book on table
design?
Nancy


"Rita Brasher" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> The parent table would be first. I'd assign a unique code to each parent,
> then create a "Parent Code" field in the student's table to which I'd
> link.
>
> Just my thoughts...
> Rita
>
> Nan wrote:
>> Hi,
>> I'm trying to create a simple database for info for dance class students
>> that includes mailing addresses and class info. Most are children, so I
>> need the parent names. A few parents have two or three children in a
>> dance class. Some students are adults. I think I need a parents table
>> AND a students table otherwise I'm entering duplicate information
>> (addresses etc.)
>>
>> Two students are also instructors but I think I can use a Yes.No field
>> for this. I can't get my head around how I link them.
>>
>> What comes first, the parent table or the students table. Most are
>> children if that makes a difference.
>>
>> Any help is appreciated.
>>
>> Nancy

On Tue, 2 Feb 2010 18:22:02 -0500, "Nan" <(E-Mail Removed)> wrote:

>Rita, Thanks.
>I began to do that but then hit a snag on how to handle the adults who are
>students and students who are adults. Also, how to record adult students
>who have children in a dance class. There are two right now. I want to
>record mailing information only once and send it only to the parent or adult
>student. I have to give it a lot more thought. I think I'm getting hung up
>on calling it a parents table when it really is an adults table.

Rather than thinking of parents and children, try considering it as households
(with addresses and phones) and students. Each Student (child or adult) is a
member of a Household; each household will have one or more Students. This
would let you apply the mailing information *to the household*; the student
table would have a field for the HouseholdID as a link, but would not itself
contain any address information.
--

John W. Vinson [MVP]

John,
Thank you for your reply. I think I understand. Do I have this right?

The main contact information would go in a Household table with a unique ID.
This would be a contact responsible for payment and care of the student if a
minor with mailing info.

Student name would go in the student table with the householdID as a foreign
key. If an adult is a student, their name would be entered again with a
link to the household table as the responsible contact. In the future, this
would enable a child of an adult student who is already in the household
table to easily be linked back to a household main contact.

I hope this makes sense, I'm typing as I think it through.
Nancy


"John W. Vinson" <jvinson@STOP_SPAM.WysardOfInfo.com> wrote in message
news:(E-Mail Removed)...
> On Tue, 2 Feb 2010 18:22:02 -0500, "Nan" <(E-Mail Removed)> wrote:
>
>>Rita, Thanks.
>>I began to do that but then hit a snag on how to handle the adults who are
>>students and students who are adults. Also, how to record adult students
>>who have children in a dance class. There are two right now. I want to
>>record mailing information only once and send it only to the parent or
>>adult
>>student. I have to give it a lot more thought. I think I'm getting hung
>>up
>>on calling it a parents table when it really is an adults table.
>
> Rather than thinking of parents and children, try considering it as
> households
> (with addresses and phones) and students. Each Student (child or adult) is
> a
> member of a Household; each household will have one or more Students. This
> would let you apply the mailing information *to the household*; the
> student
> table would have a field for the HouseholdID as a link, but would not
> itself
> contain any address information.
> --
>
> John W. Vinson [MVP]

On Wed, 3 Feb 2010 10:17:42 -0500, "Nan" <(E-Mail Removed)> wrote:

>John,
>Thank you for your reply. I think I understand. Do I have this right?
>
>The main contact information would go in a Household table with a unique ID.
>This would be a contact responsible for payment and care of the student if a
>minor with mailing info.
>
>Student name would go in the student table with the householdID as a foreign
>key. If an adult is a student, their name would be entered again with a
>link to the household table as the responsible contact. In the future, this
>would enable a child of an adult student who is already in the household
>table to easily be linked back to a household main contact.
>
>I hope this makes sense, I'm typing as I think it through.

Sounds good to me! I have a church membership database which uses the same
paradigm: a Families table with address information and a "FamilyName" field
for addessing letters to the family as a whole ("Mike & Debbie Schmidt"),
linked one to many to a Members table with firstname, lastname and other
biographical data fields. It works fine and is a good analogy to what you're
doing.
--

John W. Vinson [MVP]

John,
Just wanted to respond that the "household" concept was a great one!
Thanks!!
Rita

John W. Vinson wrote:
> On Wed, 3 Feb 2010 10:17:42 -0500, "Nan" <(E-Mail Removed)> wrote:
>
>> John,
>> Thank you for your reply. I think I understand. Do I have this right?
>>
>> The main contact information would go in a Household table with a unique ID.
>> This would be a contact responsible for payment and care of the student if a
>> minor with mailing info.
>>
>> Student name would go in the student table with the householdID as a foreign
>> key. If an adult is a student, their name would be entered again with a
>> link to the household table as the responsible contact. In the future, this
>> would enable a child of an adult student who is already in the household
>> table to easily be linked back to a household main contact.
>>
>> I hope this makes sense, I'm typing as I think it through.
>
> Sounds good to me! I have a church membership database which uses the same
> paradigm: a Families table with address information and a "FamilyName" field
> for addessing letters to the family as a whole ("Mike & Debbie Schmidt"),
> linked one to many to a Members table with firstname, lastname and other
> biographical data fields. It works fine and is a good analogy to what you're
> doing.

On Wed, 03 Feb 2010 15:14:41 -0600, Rita Brasher <(E-Mail Removed)>
wrote:

>John,
>Just wanted to respond that the "household" concept was a great one!

As an avid contradancer myself, I'm delighted to have been of help to a dance
teacher!
--

John W. Vinson [MVP]

John,
Thank you so much. I love it when I learn something new.
Nancy


"John W. Vinson" <jvinson@STOP_SPAM.WysardOfInfo.com> wrote in message
news:(E-Mail Removed)...
> On Wed, 3 Feb 2010 10:17:42 -0500, "Nan" <(E-Mail Removed)> wrote:
>
>>John,
>>Thank you for your reply. I think I understand. Do I have this right?
>>
>>The main contact information would go in a Household table with a unique
>>ID.
>>This would be a contact responsible for payment and care of the student if
>>a
>>minor with mailing info.
>>
>>Student name would go in the student table with the householdID as a
>>foreign
>>key. If an adult is a student, their name would be entered again with a
>>link to the household table as the responsible contact. In the future,
>>this
>>would enable a child of an adult student who is already in the household
>>table to easily be linked back to a household main contact.
>>
>>I hope this makes sense, I'm typing as I think it through.
>
> Sounds good to me! I have a church membership database which uses the same
> paradigm: a Families table with address information and a "FamilyName"
> field
> for addessing letters to the family as a whole ("Mike & Debbie Schmidt"),
> linked one to many to a Members table with firstname, lastname and other
> biographical data fields. It works fine and is a good analogy to what
> you're
> doing.
> --
>
> John W. Vinson [MVP]

Rita,
Thank you as well. I so appreciate it.
N

"Rita Brasher" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> John,
> Just wanted to respond that the "household" concept was a great one!
> Thanks!!
> Rita
>
> John W. Vinson wrote:
>> On Wed, 3 Feb 2010 10:17:42 -0500, "Nan" <(E-Mail Removed)> wrote:
>>
>>> John,
>>> Thank you for your reply. I think I understand. Do I have this right?
>>>
>>> The main contact information would go in a Household table with a unique
>>> ID. This would be a contact responsible for payment and care of the
>>> student if a minor with mailing info.
>>>
>>> Student name would go in the student table with the householdID as a
>>> foreign key. If an adult is a student, their name would be entered
>>> again with a link to the household table as the responsible contact. In
>>> the future, this would enable a child of an adult student who is already
>>> in the household table to easily be linked back to a household main
>>> contact.
>>>
>>> I hope this makes sense, I'm typing as I think it through.
>>
>> Sounds good to me! I have a church membership database which uses the
>> same
>> paradigm: a Families table with address information and a "FamilyName"
>> field
>> for addessing letters to the family as a whole ("Mike & Debbie Schmidt"),
>> linked one to many to a Members table with firstname, lastname and other
>> biographical data fields. It works fine and is a good analogy to what
>> you're
>> doing.