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".
Related
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.
I'm planning to log referral clicks in mysql by the country of the IP.
Let's say my table is named referral_clicks and has the columns id, referral_id, country.
I have 2 approaches in mind now:
Create another column clicks which is set to +1 for every country / referral_id. This means that I would have to check first if the row for the specific referral_id and country already exists and if not, create it.
Insert a new row for every request. My concern here is, that the table might geht messy and too big, as might get very much referral requests.
What would be the best approach now for something like that, or is there evern a better approach?
Use INSERT ... ON DUPLICATE KEY UPDATE.
I suggest you create a table with the following columns.
id (autoincrement)
referral_id
country
clickdate
clicks
I suggest you create a unique index of (referral_id,country,clickdate).
Then, I suggest you use the following SQL each time you want to log a click:
INSERT INTO referral_clicks (referral_id, country, clickdate, clicks)
VALUES ('whatever', 'whatcountry', CURDATE(), 1)
ON DUPLICATE KEY UPDATE clicks=click+1
This will start a new row for each referral id, for each country, for each date. If the row already exists it will increment clicks for you.
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.
My question might be better understood if I provide a (simplified) example of the scenario. I have two tables, Event and Course. The Event table contains EventID, CourseID, and EventDate. The Course table contains CourseID, and CourseName.
I would like to add a new Event. I understand that the query normally would be as follows:
INSERT INTO event
(EventID,CourseID,EventDate) VALUES ( NULL,'2','2011-03-01');
But instead I would like to update Event by providing the CourseName instead of CourseID. How would I go about doing this?
Edit: Apparently there isn't a way to do this with just a MYSQL query. I'm trying to do this in PHP and attempting to allow a user to update the Event record. Obviously it would be convenient for the user to add a new event based on the name of the course, preferably with a dropdown box.
Thanks
INSERT INTO Event ( EventID, CourseID, EventDate )
SELECT NULL, C.CourseID, '2011-03-01'
FROM Course C
WHERE C.CourseName = 'Course Name Goes Here';
This one one thing that you could try. Though you may want to include the date in your query or some other way to make sure you are uniquely identifying the record you are looking for.
Another thing that you could think about is storing the event id, when you bring up the reference to the event you would like the user to update. Then you would ensure that you are only updating the record that you intend to.
update Event set ....
where courseID=(
select courseID from Course
where CourseName like ''
)
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.