I have an application that needs to store calendar events for each user. One user can have many calendar events and One user can be an attendee to Many calendar events. Which I have created as below:
User:
Id
name
.....
Calendar
Id
description
start_date
....
CreatedBy -> userID in user table
Attendee -> userId in user table
My question does this effected table normalization. Would it be better to separate into a third table? Thanks
I don't understand completely what you are trying to do with
CreatedBy -> userID in user table Attendee -> userId in user table
Correct me if my model is wrong: model
If you do that, it would not be possible for a user to be an attendee on many events. One user could have many events but could only be one attendee.
So that would be the point where you need a third table because it doesn't work otherwise.
Related
In my project I have got the following tables:
Event (id, title, date, user_id)
Group (id, name, creator_id)
User (id, name, email,...)
group_user (group_id, user_id)
In the application a user can have a personal event or a group can have a event that will be shared will all users in the group.
A user is able to create an event , then the events user_id is this users ID.
Now i would like to create an event within a group - so I need a relationship between the event and the group.
Should I create the attribute group_id in the event table and leave it empty if the event just belongs to a user and not to a group?
Or should I consider creating a new table like groupEvent which has got the attribute group_id.
Or should I create a pivot table group_event that contains the groupID and the eventID as attributes.
Thanks for your help!!
One way I could think of is for you to get rid of the user_id foreign key in the Event table and instead have a User_Event table that maps users and events and a Group_Event table that maps groups and events. Not sure if this is the best design for your use case but this will avoid the need for two foreign keys in the Event table (of which one of them is NULL for every row).
Create 2 separate table Group_Event(id,group-id,event-id) and User_Event(id,user-id,event-id).
Advantages of this method is that
querying will be very easy.
you can add multiple events for a user.
you can add multiple events for a group.
But you should make sure that while adding an event to Group_Event
you should also add the same event to User_Event WHERE "User_Event.user-id" = "group_user.user_id" AND "group_user.group_id" = "Group_Event.group-id".
I am confusing about how to design table when have two table reference single column in another table.
For example, I have two type of user ( lets call them user1 and user2 ) because these two type user have multiple different information so I create two table for each of them, and each user have one account to login to system. So I create a table call account and let two table user1 and user2 reference to ID in table account. So when I have one account and I want to know which one this account belong to. It's quite inconvenient because I have to look for in two table.
Does it have solution for this problem ?
If you have an entity user, create just one table user for them.
A user is a user, no matter if he has some special role. There will be some common fields for all users, e.g. a name.
table user:
user id
user name
age
homepage
To have specific information for different types of users, you create specialisation table with information about these roles:
table role1:
user id
roleinfo1
roleinfo2
table role2:
user id
roleinfo3
roleinfo4
roleinfo5
This way, a user can have multiple roles at the same time, but you can of course limit them to just one.
If a user can only be one of those roles (that's called disjunct), you have the additional statndard way to add a column role to your user-table and put all the information side-by-side in the user table, leaving the ones that don't belong to the user-role null:
table user:
user id
user name
age
homepage
roletype
roleinfo1
roleinfo2
roleinfo3
roleinfo4
roleinfo5
Even if the user can belong to multiple classes and in case there is no overlap between the additional columns, you can of course use the last approach and add multiple flags (e.g. columns istype1 and istype2), though this is a non-standard-approach.
Update Just to clarify how you use the first solution: every user has an entry in table user, e.g. with user id = 1. This also makes sure that no user of roles user1 and user2 can have the same user id.
User id in the role tables is both primary key and a foreign key of the user table.
To make that user a user of role 1, you then add an entry to table role 1 with user id = 1. If he is (also) a user of role 2, you add an entry to table role2 with user id = 1.
You can join the tables to get the "whole" picture,
select * from user
left join role1 on user.`user id` = role1.`user id`
left join role2 on user.`user id` = role2.`user id`
This will, apart from the double id columns (that will basically can be treated as the marker istype1, istype2 in the comment to the seconds solution) and the missing role-column look exactly like the second method with just one table.
To check if user with user id = 1 is of role 1, you can check if role1.user id is null in this query, or check if user id = 1 is in table role1. To e.g. list all data for just role 1, you can use
select * from user join role1 on user.`user id` = role1.`user id`
(it uses a join instead of the left join, since and entry for role 1 has to exist).
In most cases you don't even need the specialized data, so you can just join your account-table with the user-table. In any case, you never have to worry about checking two tables (or even more, if you decide to add a 3rd kind of user).
Whats the point of the account table? If each user has one account, why don't you store the account columns in the User table.
Furthermore you can still make a parent user table for the columns they share and then make childtables for the specific users.
for example
Parent: User
Children: Employee/Customer
I'm creating a website and users can add friends. I want them to be able to see their personal friends on a page.
For exemple:
John add user Tim and Bill.
When John goes on his friends list page, I want him to be able to see that he has Tim and Bill. How do I do that? Is that even possible? Do I need more than one table? If so, does every user has to have his own friendsList table?
Yes this is possible, you do this by querying the information from the database, the answer for if you need multiple tables etc all depends on your current table structure but at the very least you need to have some way of referencing that a Person 'John' has friends, wether thats just a 'friendID' in the same 'Person' table, or another means of doing so. then it is just a matter of querying the data correctly to return what you want and bind to the websites fields :D
One way of defining the structure is the following:
Person
PersonId
Name
<other person fields>
Relationship
RelationshipId
Name --> allow to define multiple relation types like Friendship, Follows etc.
Relationship
RelationshipId
Person1Id --> FK to Person
Person2Id --> FK to Person
RelationshipTypeId --> FK Relationship
Basically, you use an n:n between Persons (anyone can have any number of friends) and also allow for other types of relationships.
Assuming you already have a table of users, one approach would be to create a "friends" table which relates users to other users.
CREATE TABLE friends (
`user_id` INT NOT NULL,
`friend_id` INT NOT NULL
);
Both user_id and friend_id would have foreign key constraints on your existing users table (so that you guarantee an id must exist in your user table in order for it to exist in the friends table as either a user_id or friend_id).
You can then link your user table on users.id = friends.friend_id to get the friend's info.
Here is a SQL Fiddle Demo showing how this works.
You should consider using an ON DELETE CASCADE constraint on the friends table, so that if a user is deleted from the user table, the associated records in the friends table are also deleted.
I created a database table with 5 columns uniqueID (auto increment), name, college, mobile, event(check box of 12 event). So my question is each time a user registers the unique id increments and iI want another event to an already existing uniqueId, is there a possible way to add/update this without going all over to the database and editing it there?
OK, following the comments, I suggest you do the following.
You need two tables.
user
- userid (unique, auto-increment)
- name
- college
- mobile
event
- eventid (unique, auto-increment)
- userid (not-unique, connects to the user)
When a user registers, you create the user record and the first event record. Then when the user adds another event, you add another event record.
UPDATE:
I was trying to teach you slowly, but peterm is right in his comment. The best way is actually this:
user
- userid (unique)
- fields relevant only to the user
event
- eventid (unique)
- fields relevant to the event (e.g., date, place etc)
user_event
- userid
- eventid (where you have a unique key that includes two fields, userid and eventid)
You might also have a college record too...
But as I said, I was just trying to get you going in the right direction.
I have 2 tables - one storing user information (id, username, password) and the second one storing information about events (id, name, description, date, username(represents the user who created the event)). I would like to implement 'favourite events' functionality. This would allow the user to store his favourite events and later display them in a list. I am not sure how to implement this in terms of design. I need a simple solution. Something like storing the IDs of favourite events in a field in the user table. I am using mysql and PHP. Can anyone point me to the right direction?
You want to have a table linking the foreign keys from the user and event tables.
Users Table:
id, username, password
Events Table:
id, name, description, date, username
Favorites Table:
id, user_id, event_id
This way you can easily access the list of favorite events.
SELECT events.name, events.description, events.date
FROM events, users, favorites
WHERE favorites.user_id = users.id
AND favorites.event_id = events.id
What you need is the most classic and basic many-to-many relationship.
You'll need extra table (let's say: user_event_ref) that will store user and event ids.
User:
id
name
Event:
id
name
UserEventRef:
user_id
event_id
In usereventref each column is a Foreign Key, and both columns are parts of Primary Key.
There's always the option to add a tiny-int field to the Events table flagging an event as a favorite. This doesn't violate normalization in that whether or not an even is a favorite has no effect on the other events. It has the added benefit of automatically deleting the event from favorites if the event is deleted.
If a sorting scheme is needed for the favorites you can still modify the events table in the same manner. If details about the "favorite" such as when it was added to the list etc is needed then you should use an additional table as suggested.