I have set up a company intranet website built with PHP/MySQL and allow users to post reviews. After joining up on this website I have grown to like the "comment" function and would like to add that same functionality to allow users to "comment" directly to other users reviews.
Currently all reviews are stored in a single table in the DB.
1) Should I create another table to then store all the comments since there can be many comments per review?
2) Once I figure out where to store these values can the rest of this functionality be built out in PHP or will other programming need to also be introduced?
Sounds like a good plan. You can have a table like Comments(commentID, reviewID, comment_body, ...). You can then insert a new entry when adding a new comment, or select all comments with a given reviewID to display comments for a given review.
Yes, you will almost certainly implement this in PHP (the same language you use in the rest of your application). You'll also have to edit some HTML, and maybe javascript as well.
Yes and yes.
Comments should be a seperate table, because they're comments, not reviews. They are two different things, therefore, they should not go in the same table.
Once you've created that table with the appropriate references to other tables, it's just a matter of constructing a query which pulls out all of the information you need (e.g. SELECT user.user_name, comment.comment_text, comment.post_time FROM comment, user WHERE comment.user_id=user.user_id AND comment.review_id = 123, where 123 is the ID of the review you're getting comments for).
The exact layout for your comment table will depend on your specific needs, but as a minimum, you'll want to know which review it's a comment for, who posted it, when they posted it, and what they actually posted.
To insert comments, create a form on the page that displays the individual review, and when filled in, create an INSERT query which inserts into your comment table.
Related
I'm currently coding a blog to get experience with php(I've made an MVC-Framework), so I am still new to this.
I have two tables important for this question:
user(id, username, password, registrated)
comments(id, content, post_id, comment_author, date, editedAt, editedBy)
In the comments-table comment_author is yet not linked to the id of the user, because I was unsure how to actually do this.
A user can write as many comments as he likes, but a comment can only have one author.
comment_author has the username in it at the moment, but I know I need the id(if the user gets deleted and someone else would registrate with this username, the comment would be his).
How should I now structure the tables?
1.) comments_author_id in comments-table, id in user as foreign key:
In this case I would have the id of the Comment author in the comments-table, but the user would not know about the comments he has written. If I want to show the recent comments of the user on it's profile, could I get them with an inner-join query then?
2.) make a new table user_comments(id, user_id, comment_id)
In this case user and comments wouldn't know about it's author/comments.
Also I have 'editedBy' in which the username of the last editing user is. Can I somehow link it with the username in the users-table or should I also link it with the id?
I am really lost with this question since I don't know much about databases; So I appreciate every help and advice I can get.
Please also let me know if I need to give any further information or change something for a better understanding.
It make sense that you go with the first option.
As you said comment has only one author so just use a foreignkey to user table.
In the second option you're creating a hole new table for a data that doesn't need a new table so you're storing data's that you don't need. also you have to write in two different tables which is two different operations for adding a comment and it gives you no extra feature that you can use.
Best way is create a new table user_comments(id, user_id, comment_id). And if you want to track every changed/edit the comment or post it's will better if you create another table for that and if user can only edit then i think it's better to editedBy fields not generate. The structure totally upto you what kind of tracking you want to be .
I'm new on programming, sorry if I can't explain my doubt very well...
My friend have a online game and I help him to manage it. The php has a table for the users (meh_users), and a table for the items that the users have (meh_users_items). Each item has a id, (column itemid) and also the users (column userid), and in the table of the items that the users have, there is a id for the combination of the user and the item. (just id, and sorry, I don't understand this so much).
There is an image, if this make more easy to understand me:
phpMyAdmin printscreen
I want to add an item (let's think that it's a sword and this item have the id 3454) to all the users, but I don't want to delete the other items that the users have. Also I don't want to insert the data on the table one by one, because it's more than a hundred users.
Hope I have said enough details!
Remember: I'm new and I already search soooo much in the internet before asking here.
I suppose you want to give that sword to all users, including ones that already have it. You don't need PHP for this, SQL is enought.
INSERT INTO meh_users_items (userid, itemid, equipped)
SELECT userid, 3454, 0
FROM meh_users
This is just an example. You need to add all field to SQL.
Three steps:
If it isn't there already, add the new item (e.g., the Sword of Power) to your meh_items table.
Get a list of all your users from the meh_user table.
Write a foreach statement creating an entry in the meh_users_items table for each user.
It also occurs to me that your database might have some setup issues. E.g., meh_users_items has a column indicating item type (e.g., weapon). That could end up being problematic. Better to keep that information with the items in the meh_items table.
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.