I need to add these two buttons to the events pages of my website.
Basically, just like any other event page you might come across online, for example Facebook,
you get the option to say whether you are attending or not attending the event.
And there is a section on the page with a number of people attending etc.
I would like to know the best solution to tackle this.
I'm not asking you to code it for me, just to point me in the right direction.
I was thinking of something like, if the user clicks attending, their username or id is put into the database where the event exists and is added to an attending field in some kind of array format. Same for if they choose to not attend but in a notAttending field.
You're half way there, at least having the concept of a user and event entities - the only step of the puzzle that you're missing is the concept of an attendance entity that stores if the user has declined/is required/is attending/failed to turn up/etc. - so each user has an attendance for each event they're invited to; in database terms this is a many to many relationship (a user can be invited to many events, and an event can be attended by many users), so would typically live in a dedicated table.
Your idea sounds good. You could have a table named event_attendants having the columns event_id, user_id and status (don't forget the primary key). That's it. status could be a ternary property so you can have a facebook-like status yes, no and not sure or similar.
You can even do the button functionality with AJAX so it's a pretty quick UI.
I would create a table called rsvps or event_responses something to that effect.
It would have three columns:
user_id - pk value of the user.
event_id - pk value of the event.
attending - boolean.
attending should be NOT NULL. That way the only data in the table is generated in two situations:
User indicates they will attend event.
User indicates they will not attend event.
If a user has not responded, they will not be in the table for that event. That you way you can easily get a count for "Attending", "Not Attending" and "Yet to Respond".
UI
Using jQuery, add two buttons to the event page: "Attending" and "Not Attending". Bind a click event to each and fire off an AJAX request when clicked. That way the interface is responsive.
Related
I've posted a few questions on here and have gotten very great help and support. I'm still fairly new to programming and I'm putting together what I thought would be a simple website for the company I work at. I apologize in advance for my lengthy post/question, I just want to be thorough and clear in what I'm asking. My question is more of needing some help getting pointed in the right direction of how to get started and some best practices to be aware of. What I'm working on right now is to create a system where a user can submit a questionnaire/online form to inquire about a specific product (in this case it's a hard money loan product). The way I am planning on setting it up is to have a database with multiple tables (users, user_info, loan_app, property) and connect these together by referencing each other. I've read about table joins and I understand them conceptually but I have no idea how to implement in practice. I've had a hard time finding actual examples.
Specifically, this is what I am doing and how I am thinking it should work (correct me if I'm wrong or if there's a better way to do it):
1- the user (aka the borrower) signs in to the website. The user log in system references the user table where things like first name, last name, user name, password and user ID are stored. I have included an "active" column in this table so that when a user logs in the condition for them to get into the website is that the username and password match AND the user is activated. This way we can control on the back end certain user accounts access. I have this part working.
2- when the user registers, they only fill out the information that creates a new record in the "user" table. I have created a second table called "user_info" that will contain other data like home address, phone number email etc. But I need to be able to associate the correct record with right user. This is my first issue to wrap my head around. My thinking behind doing this instead of simply putting all this information in the user table is that for one, I might keep adding to that table and make it very big, and two for security reasons, I would like to keep the information separate. I don't know if this thought process has any merit to it though. Again, that's why I'm posting this here.
3- The user, once logged in, clicks on a button on their home screen/dashboard that will take them to the loan "pre-approval application" form, which is the questionnaire. On this form their basic information will be echoed/posted from the "user_info" table to pre-populate certain fields like first name, last name, email, phone number, address etc. So going back to #2 making sure I can associate the user with the correct record in the "user_info" table is critical. THEN, there are additional fields that the user has to fill out in order to submit the application/questionnaire. These form fields will create a new record in the "loan_app" table. This table will have a loanid column that is the primary key for that table, and an auto generated/randomized 6 or 7 digit loan number (loannum). The loanid will be a hidden value but the loan number will be like a reference number that is associated with the loan for the life of it and used for later accounting and recording purposes internally, whether or not it actually becomes a loan. The loanid, I'm assuming here, is the Foreign key in the "user" table and the userid is the Foreign key in the "loan_app" and "user_info" tables correct? If so, how do I incorporate being able to simultaneously associate all these records when the loan application/questionnaire is submitted? My thought would be write individual php scripts that does each of these things separately then have a "master" php that includes all of those individual ones that is placed as the form action associated with the submit button on the form.
Thanks for taking the time to read through this. I'd really appreciate any advice or reference material that I can read up on to learn more about this stuff. My job has a pretty crazy schedule and I travel a lot so I don't have the time to take actual classes to learn this stuff formally. I'm pretty much doing this as I go.
Also, I'm using MAMP with mysql, not sure if that helps any or not...
The user table's primary key userid can be the primary key of the user_info table as well, since each user will have only one user_info record, right? A foreign key constraint is good to ensure only valid userids get recorded in user_info.
The loan_app table can contain a denormalized relationship from loanid to userid so that each loan application is associated with a user. Again, use an FK constraint for integrity.
Don't include loanid in the user table - that would mean each user has a relationship to a single loan application. You already have the one-to-many relationship you need in the loan_app table.
I'm building timeline, that will show all things that users does, ( events ).
Example events:
User has joined site ( registration )
User has added post
User created public event
User joined some random group.
User has added a comment into forum or group.
Problem is that i don't know how to structure database, that will keep all events and show them in timeline.
Visual example:
I'm using Laravel with eloquent. I thought on all actions i could raise events, and them listen to them and add all events to database events table.
At example, when user registers, event is raised, and data is put to database, then script gets all events from database and structures them by date.
But problem is that all events has different content, at example, when user registers, I need to store only registered user foreign key that points to users table, but when user creates a post, I need to store his foreign key, and foreign key that points to created post.
So question is how, to structure database, that will keep all events for displaying them on timeline, assuming that event contents for each action can be different?
I would use polymorphic relationships:
http://laravel.com/docs/4.2/eloquent#polymorphic-relations
So your events table would look like this
Events
id
user_id
eventable_id
eventable_type
event_class
You would have a user relationship, and an eventable polymorphic relationship, which could point to a post, or back to a user (for registration).
I also added an event_class field, which could store the name of a class to handle how the event displays (you could have a class to handle New Post events, for example). I might even omit that and resolve the handler class somehow from the eventable_type column.
Depending on how you want it to work, you could also store the title and body in the database table, but I'd prefer to use a class to generate that on the fly.
I am trying to get my head around an issue relating to database logic.
I have a system that is to allow the user to create an event, performances and multiple different ticket types for a given event. These will then be added to the database with prices relating to the ticket types for a given event (the ticket types can be reused for other events and there is no set number of types for each event) and then a customer will go onto the site, select one of the events, performances and will then have listed for them to choose from the different ticket types with prices.
At this point I have a table for events which is using a series to store the ticket ids which are stored in a separate table and yet another table which stores the prices. The use of the series is ridiculous as it tends to crap out on me and either fails to work (as mysql doesn't handle the code properly) or it is incredibly limiting on what can be done with the info Has anyone any better idea how I might achieve this result?
example of an event:
event name: 'event 1'
performance: '23/03/13 (12:30)'
ticket types: Adult (€20), Student (€15), Special (€10), etc
the person setting up the event can create any ticket types they want or use existing ones in the system and just have a price set for this particular event.
If I understand you correctly, I believe what you are doing is most likely the best way to do it.
A user can create multiple events, each of which can have a variety of tickets. Tickets are not specific to an event (can be used on multiple events), and thus the price can not be stored with the ticket information.
Therefore, what you want to do is have these tables:
events - Stores information on the event
tickets - Stores information on the ticket
*events_tickets* - a join table for events and tickets (As it is a many to many relationship)
The events_tickets table would have columns like so:
primary id, event_id (Foreign Key), ticket_id (Foreign Key), price
Hope that helps.
table Event: Id_Event, Ds_Event, Dt_Event, Id_Venue
table Ticket_Type: Id_Ticket_Type, Ds_Ticket_Type, Ic_Ticket_Type_Is_Custom (boolean)
table Event_Ticket_Type_Price: Id_Event, Id_Ticket_Type, Nr_Ticket_Price
table Venue: Id_Venue, Ds_Venue, Ds_Venue_Address
I would like to make it able for my users to add each other as friends. I just don't know exactly how to do it.
I have a table called "members" where the users have (ofc) and ID,username,pass etc etc. and then I was thinking of creating another table called "friends", where I was planning to have the rows -> username (the friend added) and friend_to (who the friend 'belongs' to).
But; I just don't know - how I should make the "add friend" link, and make it INSERT INTO the table? Can I make an onClick on the link, or what should I do? :-s
Thanks in advance.
Have a table called friends have rows, (id, user_id, friend_id, status, time)
id is the index, user_id is the one requesting friendship, friend_id is the receiver, status is the status of friendship like pending or declined, and time is the timestamp of the time when the request was sent.
Then in a php code check if the users aren't friends then let them add each other as friends. One way you could check was like this
(SELECT COUNT(*) AS total WHERE (`user_id` = ".$_SESSION['user_id']." AND `friend_id` = ".$_GET['friend_id'].") OR (`user_id` = ".$_GET['friend_id']." AND `friend_id` = ".$_SESSION['user_id']."))
the above code will check if they are users, and if they are you would not let them re add each other, if they aren't the user gets a button to add them to friends, where it inserts into a database new row, with user_id being the user sending and friend_id the user's page the sender is submitting the button from
On the backend, you will need separate PHP functionality (easiest way is to simply have a separate PHP page) to handle the result of the "add friend" link. Your table layout seems adequate from what you have describe. The "Add Friend" link will need to send a request back to the add_friend PHP handler which includes ID of the user and the ID of the user they added. And this handler will be where you include the MySQL code for performing the insert, based on the data that is provided to it.
On the front end, you can have the link send them to a new page, or you can use an onclick event to issue an AJAX request and update things behind the scenes without requiring a page reload. That choice is up to you and what fits your design best. The later is more complicated and will require some Javascript and/or jQuery to handle the AJAX parts, but it often results in a more pleasant user experience.
I have a simple social network project going and I would like to add a simple recommend this user profile function. A logged in user can 'recommend' a user once - its just like the 'This ansewr is helpful/not helpful' buttons here on posts in Stackoverflow. I want a simple table design to implement the exact idea - any tips?
A user can recommend any user ONLY once and likewise each profile would have a simple tally saying - this user has been recommended X times. Its just a number nothing real fancy or so...
[Recommender, Recommendee, Recommendation] PK being the first two fields ?
Since it is a many-to-many relationship, you will need a separate table- unique id (auto increment), recommender (userid), recommended (userid).