I am learning PHP the fun way, by making something useful. I'm making a personal PHP/MYSQL website for tracking watched episodes of tv-shows, and it's going quite good so far, albeit messy.
I have a user table, a episode table and an series table. Each of these are self explanatory I guess. What I want to do is make each user in the user table able to track what episodes have been watched. (Each single episode is in the episode table with a field that joins it with the Series table to keep track)
What I cannot get my head around is this:
How can I track if said user has watched said episode?
The only solutions I've come up with is
Add a field in the episodes database with the userID and mark them as 0 or 1, which isn't a very nice solution.
Even worse; each user has a "watched_id" field with several values for each watched episodes.
I know enough to know that this is not a good approach,
how can I approach this more effectively?
You need to create a many-to-many relationship using a mapping table ie. named "watched" with the following fields
id
user_id
episode_id
watched_at
...
Hope that helps. There is a lot of documenteation on the net if your searching for "many-to-many relationship", here is just an example:
http://www.joinfu.com/2005/12/managing-many-to-many-relationships-in-mysql-part-1/
Related
Hi I'm just getting into PHP and MySQL and English is my second language so excuse me while I try to describe my question well.
I'm trying to create a feedback system where students can leave feedbacks about teachers. A student log in pick a subject first, then find a teacher who teaches that subject and can leave feedback of that teacher. All the feedbacks of a teacher can be seen by public(no require login) And the teacher can log in have look at the feedbacks and mark them as read, once a feedback is marked as read it won't be shown publicly again .
The problem I'm having is not about the idea itself or the login system etc, it's about the database structure. Mainly the teachers feedback database, first the teachers are categorised by subjects, then each individual teacher need to store feedbacks, and those feedbacks can be active(not read yet) or inactive (read).
Since I'm new to PHP and MySQL I don't know how to design the database to be effective, let's give a problem as a example "Display the numbers of active feedbacks of a teacher" I can think of few ways to approach this, but can't decide which way is the best.
SOLUTION 1, One massive database to store everything , First it needs to filter the database by the subjects, then filter by the teacher name/id then filter out the inactive one then count up how many active feedbacks are there
SOLUTION 2, give each an individual database, and when the student leave feedback it gets stored directly into an active database for that particular teacher , when the teacher mark it as inactive it will be moved to a different (inactive) database of that teacher, so to find out the numbers of active feedbacks just simply count the number of data in that active database.
SOLUTION 3, combine solution 1 and 2, because each teacher can only teach one subject, so we create big databases for each subject, and for each subject we create an inactive database where we store inactive feedbacks, when a feedback is marked as read it will be transferred to that database. Then to find out numbers of active feedbacks we can filter the subject to find the teacher and just simply count up the numbers of feedbacks that teacher have because all the inactive ones will be at a different database.
I hope I did not confuse you with my description, I would really appreciate if any of you can tell me the most efficient way to build database for this problem in PHP and MySQL. Thanks!
Edit 1: sorry I do mean Tables rather than databases, so the question is whether I should create multiple tables for this problem or stick with one.
You could first have student table and teacher table. In your feedback table you can have columns: student, teacher, comment, time
Its better to have multiple tables,for teachers and students and it would be good if use log in functionality too.mainly make sure that design a over all flow of steps,its doesn't be be good choosing subjects and teachers separately,think it in such a way that as soon as you select subject an subject,the appropriate teacher of that particular subject should be also be selected.Better create an clear flow of implementation.
I'm super new to CakePHP. I've searched everywhere for this but I can't seem to be able to get it right, or find any sort of orientation. I still don't get how the whole HABTM thing works and I'm expecting to learn more from this.
I'm trying to do a Twitter-like system, with users and followers, and posts (tweets) and shares (retweets). I've set up the users and posts models, and join tables for followers (between users and users) and shares (between users and posts). How should I set up my model associations? I've been trying several ways but I'm not certain on whether I'm doing it right or not.
And the other question is, what would be the proper find query to get all posts by the people I follow, plus the posts they've shared, without getting all the unnecessary data like user info and such, just the posts in one array? Is it possible with find in one query, or should I do several and then merge the arrays? Plus, it would be extremely useful to understand how to properly filter and limit this rather complex query (obtaining a "posts timeline" between certain date ranges, limit the posts to a certain amount, or both).
I know my question is a little bit silly, but I swear I've done a lot of research and I can't seem to be able to get it right. So any help, especially with the query part, would be greatly appreciated.
Thanks!
So these would be some weird relationships. I'm feeling you should have the following tables:
Users (with alias Followers) hasMany tweets
Posts belongsTo Users
UsersFollowers (A HABTM table)
To make this work on just three tables, Posts would need to be a threaded table. In essence, if a person retweets (shares) a post a new record is created with the id of the original post in the new posts parent_id column. Then when the record was called the model could pull up the additional data and include it in the feed.
The alias aspect of Users allows for the follower part to be done in just one table. To find followers of a person, search with one key of the table (follower_id) and to find the people a person follows just search with the other key (users_id).
As for the second part of your question, finds should be pretty easy in this setup, but you might want to read up on Containable and threaded queries. You could include timestamp columns in the tables so you could later do a search by date feature (or a post timeline).
I am working on a little project where a user submits an article to MySQL, and then PHP send the post to the screen. So far so good.
Now i want to extend it to a "two level" post system, where people can comment on the articles.
The case is, i dont know how to do that.
The table i use for storing articles:
TABLE: posts
id user date avatar signature post
Should i make a new row named comments in the posts table, or should i place the comments in a seperate table? one for articles, one for comments?
All help is much appreciated.
Depends on how you use it on your website. You have to ask: "are my articles and comments essentially the same concept?" If yes, then use one table, if no, use two. On most websites articles work differently, can be categorized, editted etc., and usually need a different fields which would clutter the comments table... so in that case two tables are more reasonable. But if you conclude that on your website articles and comments are generally the same (but try to think future proof: wouldn't you need to add some article functionality in 2 months?) then you can think of articles also as of comments and have one table for them.
If you decide to merge things to one table, and you realize that you need another column to distinguish type of the post, and that some columns remain unused for some types, it is a clear warning signal you should have two tables!
This is a little subjective, but I would just set up a parent/child relationship on your posts table, make a parent_id column that is a foreign key for the id column in the same table. for extra credit, you can make it a nested set relationship which will allow you to pull the parent and all the children in one query
In my database are 2 tables: "books" and "users". I'm displaying all the books on a page and would like the option for a user to click a little link "I've Read This", similar to Facebook's Like function with statuses. The user could click that they've read the book or unclick to "unread" the book. Other users logged in could also see who has read what. I'm questioning my approach and would like to get feedback on other directions to take for something like this.
What I had in mind was to have a field in the "users" table, maybe something like "books_read", in which I would store an array of values (book_id's). On the frontend where all the books are displayed, I would query the "books_read" field and if a value matched the current book_id, then underneath that book would be something like "User X has read this".
In short, I would store an array of "book_id"s in the "users" table to collect what books each user has read. I would pull this array and compare IDs to each book queried, and if there is a match, output that the user has read that book.
Am I missing something or maybe not looking at a cleaner approach?
In a RDBMS such as MySQL, it's rarely ever a good idea to store lists in a field, especially when you know you will be looking for specific pieces in the list later on. The database can not take advantage of an index by doing that.
Instead, you should make an additional table that links users and books read. Optionally, you could call it *users_books* and move read in to its own column.
users_booksread
-----------
user_id
book_id
Create a separate table, perhaps called book_read.
In it, for each book a user likes, store the user_id and the book_id.
Then you don't have messy arrays to deal with, everything is normalized, your design will be cleaner, and your database more flexible. Additionally, your user table won't have a bunch of extra crud bolted on to it that will affect performance in unfortunate ways.
I have a site that scrapes all the episodes from tv.com from certain series.
So my database has a User table, a Show table, an Episode table, a Show_User table (to associate shows with users, HABTM), an Episode_Show table (to associate episodes with shows, HABTM), a Episode_User table (to associate episodes with shows, only as a way of marking them as 'watched').
Now I want to add a way of marking an episode as 'downloaded' too.
So at the moment, the Episode_User table has two fields, Episode_Id and User_Id. Should I create a new table entirely for this? Or just add a field to the Episode_User table?
I'm using CakePHP's automagic features, and don't particularly want to break it. But if I have to, I have to...
Thanks for any advice.
I don't see why you would want to create a new table for episodes a user has downloaded. To me it would make the most sense to modify the Episode_User table to have a field for watched and a field for downloaded, since it's all relating back to the same pair of entities, users and episodes.
However, any time I've stored information about a relationship between two tables in that manner, I've found that regardless of the framework I'm using, the ORM inevitably become more complicated, but I don't think there's any way around there.
With CakePHP for handling those kinds of complicated situations, read up about the model behavior, Containable. It's not very well documented in the CakePHP book, but is really quite useful in a situation where you need to use the fields in Episode_User, for example, if you needed to find all of the users that had watched a particular episode, but not downloaded it.
Also, it occurred to me, while reading your post, that you could possibly make your data model more simple by having a hasMany relationship between shows and episodes. An episode will never belong to more than one show, so your episodes table could just have another field, show_id, which related back to the show table, and you wouldn't even need the Episode_Show table.