Having the users and lost passwords in the same table implies a 1-1 (or 1-0/1) relationship; 1 user has 1 lost password (or none, if the column is nullable).
If that's the cardinality of the relationship, having them on the same table is correct. The school of thought that refuses nulls (which depending on the day, I adhere to), says that if the relationship is 1-0/1, you should:
users
usersID primary key
lostPasswords
usersID primary key references users(users_id)
-- lost password columns here, non-nullable
The relationships look fine, however, I would suggest you use a diagramming tool which shows which are the columns referenced. Surprisingly, I've only found SchemaSpy doing this: http://schemaspy.sourceforge.net/sample/diagrams/summary/relationships.real.compact.png
Something like this:
Party
id
type: {individual, group}
name
PartyRelationship
fromPartyId
toPartyId
type: {groupMembership}
Event
id
name
scheduledStart
scheduledEnd
actualStart
actualEnd
EventRole
eventId
roleType {organizer, scheduler, participant}
partyId
List
id
eventId
name
ListItem
id
listId
description
createdBy /* should point to a party */
An Event hasMany Roles, which could be organizers, participants, etc.
A participant can be either an individual or group, both of which are subtypes of Party
A Group party has many Individual parties, as described in the PartyRelationship table. An Individual can belong to zero+ groups.
An Event hasMany Lists, and a List hasMany Items. A list belongsTo one Event, and a ListItem belongsTo one List.
Example usage:
insert into party values (1, 'individual', 'neil');
insert into party values (2, 'individual', 'bernk');
insert into party values (3, 'individual', 'simon');
insert into party values (4, 'individual', 'ypercube');
insert into party values (5, 'group', 'canadians');
insert into partyRelationships values (5, 1);
insert into partyRelationships values (5, 2);
/* now neil and bernk are related to the 'canadians' party */
insert into event values (1, 'an event with canadians and ypercube, organized by simon', '2012-07-01', '2012-07-02');
insert into eventRoles values (1, 'organizer', 3); /* simon is the organizer*/
insert into eventRoles values (1, 'participant', 5); /* the 'canadians' group is a participant */
insert into eventRoles values (1, 'participant', 4) /* ypercube is a participant too */
Best Answer
An "Event" has a Creator ("users can create an Event"), Members (those who have "Joined" and not "Left" the event) and a Location.
You should have the entity Event with EventID, Creator, other fields such as Location, description, category, date created (optionally) Represented as an Event table with EventID, CreatorID (foreign key to Users table), maybe other fields as needed.
Then have a table EventUser or similar, which is a "bridge" table between Event and User. Field names EventID, UserID which keeps track of users registered to the particular event.
User table is self explanatory with UserID plus whatever other fields are needed for the user.
Do you need to keep track of the "history" of created/deleted event, joined/left event? Then add appropriate tables accordingly and ensure the event is updated accordingly. e.g. add an entry to a table saying that a User was added or deleted to the particular event. You could do this via the business logic in the application itself, or perhaps with an update/insert trigger.
Presumably only the Creator of an event can change details such as the date and location, so you will need to take that into account in the way your application updates these.