Prev: Update Table
Next: Proper Table(s) Layout
From: .:RoKsTaR:. on 6 May 2010 00:33
Hello again :) I should have bookmarked my last thread so I could add to it :P

Here goes again ;)

Ok this is what I have so far :) How's it look?

address - addressid, address, city, province, postalcode
phone- phoneid, phonenum, extension, phlocation
email - emailid email, emailLocation
webidentity – webidentityid, imaccount1, imaccount2, twitter, facebook,
linkedin, website

people – peopleid, firstname, lastname
people_address – id, peopleid, addressed
people_phone – id, peopleid, phoneid
people_email – id, peopleid, emailed
people_webidentity – id, peopled, webidentityid
relation – id, peopleid, peopleid
student – id, peopleid, lessonday, gender, age, status
guardian – id, peopleid, relationship, primarycontact (this is a yes or no
field)


Notes on this table:
I'm a music teacher who teaches an average of 50 students at a time. I'm
trying to build a database track contact info, invoice students, and track
attendance. I'm starting off with the contact portion of the database and
once that is done I'll move on to the rest.

Cheers!
From: Jeff Boyce on 6 May 2010 14:33
Your [student] table raises some questions, but the rest look pretty good.

When ever I see [age] as a field, I wonder if you're willing to go back
through your table every day or so and update that field to reflect their
ages AS OF TODAY!

Also, I question [lessonday] and [status] as attributes of a person who is a
student. Will you never have more than one of these sets per student? If
you do, how do you distinguish one record from another?

(a bit more info, please...)

Regards

Jeff Boyce
Microsoft Access MVP

--
Disclaimer: This author may have received products and services mentioned
in this post. Mention and/or description of a product or service herein
does not constitute endorsement thereof.

Any code or pseudocode included in this post is offered "as is", with no
guarantee as to suitability.

You can thank the FTC of the USA for making this disclaimer
possible/necessary.

".:RoKsTaR:." <RoKsTaR(a)discussions.microsoft.com> wrote in message
news:C32FA4BA-4CCB-4BAE-9D41-3967B782C113(a)microsoft.com...
> Hello again :) I should have bookmarked my last thread so I could add to
> it :P
>
> Here goes again ;)
>
> Ok this is what I have so far :) How's it look?
>
> address - addressid, address, city, province, postalcode
> phone- phoneid, phonenum, extension, phlocation
> email - emailid email, emailLocation
> webidentity - webidentityid, imaccount1, imaccount2, twitter, facebook,
> linkedin, website
>
> people - peopleid, firstname, lastname
> people_address - id, peopleid, addressed
> people_phone - id, peopleid, phoneid
> people_email - id, peopleid, emailed
> people_webidentity - id, peopled, webidentityid
> relation - id, peopleid, peopleid
> student - id, peopleid, lessonday, gender, age, status
> guardian - id, peopleid, relationship, primarycontact (this is a yes or no
> field)
>
>
> Notes on this table:
> I'm a music teacher who teaches an average of 50 students at a time. I'm
> trying to build a database track contact info, invoice students, and track
> attendance. I'm starting off with the contact portion of the database and
> once that is done I'll move on to the rest.
>
> Cheers!


From: .:RoKsTaR:. on 6 May 2010 17:20
I'm gonna change it to DOB but have a function to calculate by the date
entered whether the student is a child, adult, or teen. For adults, I'll
just enter a generic date like 01/01/1992 so they don't need to give me their
info unless they want too ;)

Status distinguishes between current or retired student
Lesson Day just tells me which day their lesson is on. This changes
throughout the year for some students depending on their schedule

"Jeff Boyce" wrote:

> Your [student] table raises some questions, but the rest look pretty good.
>
> When ever I see [age] as a field, I wonder if you're willing to go back
> through your table every day or so and update that field to reflect their
> ages AS OF TODAY!
>
> Also, I question [lessonday] and [status] as attributes of a person who is a
> student. Will you never have more than one of these sets per student? If
> you do, how do you distinguish one record from another?
>
> (a bit more info, please...)
>
> Regards
>
> Jeff Boyce
> Microsoft Access MVP
>
> --
> Disclaimer: This author may have received products and services mentioned
> in this post. Mention and/or description of a product or service herein
> does not constitute endorsement thereof.
>
> Any code or pseudocode included in this post is offered "as is", with no
> guarantee as to suitability.
>
> You can thank the FTC of the USA for making this disclaimer
> possible/necessary.
>
> ".:RoKsTaR:." <RoKsTaR(a)discussions.microsoft.com> wrote in message
> news:C32FA4BA-4CCB-4BAE-9D41-3967B782C113(a)microsoft.com...
> > Hello again :) I should have bookmarked my last thread so I could add to
> > it :P
> >
> > Here goes again ;)
> >
> > Ok this is what I have so far :) How's it look?
> >
> > address - addressid, address, city, province, postalcode
> > phone- phoneid, phonenum, extension, phlocation
> > email - emailid email, emailLocation
> > webidentity - webidentityid, imaccount1, imaccount2, twitter, facebook,
> > linkedin, website
> >
> > people - peopleid, firstname, lastname
> > people_address - id, peopleid, addressed
> > people_phone - id, peopleid, phoneid
> > people_email - id, peopleid, emailed
> > people_webidentity - id, peopled, webidentityid
> > relation - id, peopleid, peopleid
> > student - id, peopleid, lessonday, gender, age, status
> > guardian - id, peopleid, relationship, primarycontact (this is a yes or no
> > field)
> >
> >
> > Notes on this table:
> > I'm a music teacher who teaches an average of 50 students at a time. I'm
> > trying to build a database track contact info, invoice students, and track
> > attendance. I'm starting off with the contact portion of the database and
> > once that is done I'll move on to the rest.
> >
> > Cheers!
>
>
> .
>
From: John W. Vinson on 6 May 2010 18:26
On Thu, 6 May 2010 14:20:05 -0700, .:RoKsTaR:.
<RoKsTaR(a)discussions.microsoft.com> wrote:

>I'm gonna change it to DOB but have a function to calculate by the date
>entered whether the student is a child, adult, or teen.

Agegroup: IIF(DateDiff("yyyy", [DOB], Date()) < 13, "Child", DateDiff("yyyy",
[DOB], Date()) < 20, "Teen", "Adult")

should do it...
--

John W. Vinson [MVP]
 | 
Pages: 1
Prev: Update Table
Next: Proper Table(s) Layout