Design advice please...

Without a more thorough understanding of your database schema and the
business model you're trying to implement, I can only offer suggestions.
First I think using NULL to handle these values can make sense. However in
this case, I expect that I would create a Member table that had a MemberID
and MemberType columns. I would also create StudentDetails, AffiliateDetails
and RegularDetails tables and cross-reference these on the MemberID PK/FK.
This way you could hold common columns in the Member table and type-specific
information in the FK tables.
hth
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
Microsoft MVP
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________
"Matt" <awpilotnospam@.aol.com> wrote in message
news:jz6yc.66258$3x.20120@.attbi_s54...
> I'm developing a database for someone that will involve user accounts.
The
> accounts will hold certain data. There are different types of users: e.g.
> regular members, affiliate members, and student members. The problem is
> that not all the accounts will hold the same type of data. The difference
> between a regular member and a student member is that the regular member
has
> a doctoral degree, a date at which that degree was received, and some
other
> information; the student member has info about their current institution,
> degree type, and a faculty sponsor name.
> I think it would be unwise to put all these fields into one table and then
> leave null whichever fields are unneeded.
> Would it be good practice to have a users table with user name, password,
> email, and member type (regular, student, etc.) and then have separate
> tables for each type of member? For example, separate tables for regular
> members, student members, affiliate members, etc.
> Thanks.
> Matt
>
> Without a more thorough understanding of your database schema and the
> business model you're trying to implement, I can only offer suggestions.
> First I think using NULL to handle these values can make sense. However in
> this case, I expect that I would create a Member table that had a MemberID
> and MemberType columns. I would also create StudentDetails,
AffiliateDetails
> and RegularDetails tables and cross-reference these on the MemberID PK/FK.
> This way you could hold common columns in the Member table and
type-specific
> information in the FK tables.
Thanks!
Matt