Easy checklist database design question.

[ninefoureight]

Hi there im just about to start a new database, but i cant decide within myself what would be the best table design. The database is going interface with my site where a user logs in, and can check off the Munros (hills over 3000ft in Scotland) as they do them and it retains it on their record. There are over 200 Munros so there is a lot of YES or NO answers to store for each user.

Basically how i forsee this is to be done is 1 table with users, users password, email. then a 2nd table with the list of munros i think i need a 3rd table but i am unsure of what i should be storing there. I think im overlooking something easy here and if some1 could add give me a nudge i'd appreciate it.

 

[Mile-O]

tblUsers
UserID
Forename
Surname
Password
Email
etc...

tblMunros
MunroID
MunroName
etc...

tblAchievments (couldn't think of a better title )
UserID
MunroID
DateClimbed
etc...

You never said, however, what these "othwer questions" are.

where the key is:
Table Name
Primary Key
Foreign Key
Field

 

[ninefoureight]

You never said, however, what these "othwer questions" are.

where the key is:
Table Name
Primary Key
Foreign Key
Field [/B]

Thanks Mike, certainly a nudge i needed. I think i was looking for a shortcut something like a new table was created for every users record.

I'm not sure what you mean by "othwer questions"?

I will in time use the User Table for further projects but for now im aiming just to keep it based on the Munros climbing. Thanks

 

[Mile-O]

Mile; not Mike.

By other questions I thought you might have been meaning a "Did it have a nice view from the top? Yes/No" type of questionairre but I see you just meant Yes/No for "Climbed?"

The tblAchievements is, basically, a junction table to create a many-to-many relationship. One climber can climb many munros; one munro can have many climbers.