I write script and form for comment for my movie website but I don't know how to store each comment in his table column in database for specyfic movie.
for example,
I have to movies on this image http://prntscr.com/65wilp
So, I want when I post comment on movie 95ers Time Runners 2013 to store that comment in column for that movie, and comment for Guardians of the Galaxy 2014
in his column.
Thanks
You need more database tables. Learn more about relationships. You need two tables. Movie_table and comments_table. The relationships between two is 1:N.
This says, The ONE movie has a MANY comments.
Try put hidden input to the comment form named movie_id. If you list movies from Movie_table you can fill this input with a correct ID of movie row. Next, if you send the comment, you know the id of movie and you can make the relation of comment to movie (via foreign keys).
this can help you to make tables http://www.databaseprimer.com/pages/relationship_1tox/
and this can make you get more skills https://howtoprogramwithjava.com/database-relationships-one-to-many/
Related
I'm designing a site where comments can be added in reply to an initial post and each comment can have attached images (and likely will given the type of content). I'm wondering how I will grab the proper comment ID to insert it into a MySQL DB column in the image table.
So far the db has a table for the initial post with serial as the primary key, the db also has an image table with id as the primary and columns for various attributes of the image as well as a column for the serial of the post images belong to (serial comes from the serial of the item the post is about), I plan to also add a column to that table for the comment ID which will be filled with the ID of the comment they belong to if they don't just belong to the initial post. I'd like to add comments in their own table with ID, info, date and title.
What I'm unsure of is when inserting a comment with attached image, how do I grab the comment ID to insert into the image table comment ID column? Or is there a better way to approach the issue?
Thanks in advance for any advice.
I have a MySQL database set up with a list of all my movies, which I imported from a MS Access database. One field contains the possible values for the genre of the movie, movies can have more than one genre, so I need a data type which supports this feature. In access I could link one table 'genre' to the field 'genre' in my table 'movies', so I could choose none, one ore multiple genres per movie. When I switched to MySQL I used the SET data type to define all the possible values. So far everything is running perfectly.
I am now trying to set up a table in html/php to show the mysql table. I want the table to be able to sort on: title, genre, quality, rating, etc. But for the sorting on genre, I would need the possible values from the set data type. I don't know if it is possible to get the values with some php command/code, but after I lurked around on the web for a while, I didn't see many applications where they use the SET data type for obvious negative reasons.
So I started looking into the Foreign Key possibility. The problem I have here is that -for as far as I know- the key can only contain one possible value, which puts me right back at the start of my problem. I do like the idea of a foreign key, because it would make it way easier for me to add a new genre to the list.
Is there a possibility I am overlooking? Is it possible to either get the values from the SET type to php or to use a foreign key with multiple possibilities for one record?
I know I can also put every genre in my php script manually, but I'd like to have it all on one place. So that if I add a movie with a genre I haven't defined yet, I can just update it at one place and everything else adapts to it.
Dagon is absolutely right here - you have an issue with the structure of the tables in your back end. You are wanting to model a many to many relationship when at the moment with your current back end the best you can do is a one to many relationship.
To review:
You have individual films that can have many genres
And you have individual genres that are related to many films
Relational databases actually don't model many to many relationships with one relationship they use recursion of the one to many relationship and create two joins.
To model a many to many relationship you need three tables
A film table (which I think you already have)
A genre table (which I think you already have)
A junction table which as Dagon suggests will consist of two fields film id and genre id.
You then set up two separate one to many relationships. One from the film table to the junction table and one from the genre table to the junction table.
Now if you want to know all the genres a film is in you simply filter the junction table on the relevant film id and if you want to know all the films with a certain genre you filter the junction table on the genre id.
Set up lookups to relate your genre ids to textual descriptions and bang you are free to change the textual description as much as you want and the great thing if you've done it right it will upgrade every single value in your forms.
This is an absolute fundamental concept of the algebra of sets behind the design of SQL and relational database design.
I want to create a posting system to a profile. I created a database for storing all users posts each user have a table.
Ihad created another database for storing the comments of each posts. My logic is to create each table in the comments database and store each comment in that.
Is there a logic to link the post and the comments. I thought to use mysql last insert id but it will return last id which will create error because one of the post will not have a table.
Is there any other way?
Another way would be to have a single table for posts, and identify a user post in the table using a userid column. To find all posts by a particular user, simply query by the user's ID. By doing so, you have a single table to manage, and you can do a lookup easily. If you create separate tables for each user, you have to create additional logic to first figure out which table to use. If a user is removed, you delete a table, rather than simply removing some rows from a common table.
The same logic applies to the comments table - add columns for postid',commentid,userid`. Again, a single table contains all the comments. To find comments on a particular post, you would do a simple query such as
select comment_text
from comments_table
where postid = ?
The whole purpose of using MySQL is to leverage relationships between entities, i.e. a user owns posts, a post is linked to comments.
If you do not want to use a relational schema like this, take a look at NoSQL DBs.
You have a couple options here:
Add a user_id column to your posts table, and a post_id, and user_id column to your comments table. You can then setup foreign keys with one-to-many relationships.
Only use a single table that has (in addition to your existing) a user_id, and type column. Type will define comment/post/etc. This can be defined with intermediary tables as a number mapped to a CONST, string, or any other way that you see fit (intermediary best option imho).
Vary the above example and use 2 intermediary tables to match users to posts and comments to posts (possibly also users to comments).
I am new to MySQL and PHP. I am having issues wrapping my mind around how to accomplish something. I am building a site that has basically a forum style post page. Users enter text into a textarea which then posts that text along with a timestamp and $_SESSION['Username'] into a MySQL table titled "campaigns." So the table has postEntry, postName and postDate rows currently.
On this same page that I have the form, I then display the entire contents of the campaigns table into a div. So it can show each post in descending order.
This has been working great for me, but I am now trying to look at the bigger picture and am thinking this is not a good way to do what I need. I basically need the ability to have an endless amount of "campaigns" each with their own set of posts. Then give the user the ability to select which campaign they want to view and show corresponding posts for that campaign in the div.
So the real question is: Is there a way to do this with just one table. Or would each campaign need it's own table in the database?
Add a campaign_id to the POST table and viola!
edit: more info:
you need one table for the campaign like so:
Campaign
-------------
campaign_id
name
then you need another one for all the posts
post
-------------
post_id
campaign_id
post_time
name
this way, each post is associated to a specific named campaign.
I am new and trying to make a simple website for a project. I have to pages, add and view hobbies. User needs to be able to add 1 or more hobbies and store it in a database and to retrieve it in another page, i have listed what i plan to do below.
How do i make it such that I am able to store multiple hobbies for users in the database?
Using MySQL, HTML, PHP, Dreamweaver
Assume: User has been created, user has been logged in and all user related database coding has been done. More than 1 user exists, all users are to have a few hobbies each.
Database
User table: UserId, Username, HobbyId
Hobby table: HobbyId, HobbyName, HobbyDaysAWeek
1 user can have 0 or more Hobbies.
Add hobby page
dropdownlist (binds list of hobbies from hobby table)
textbox (for user to enter how many days a week he spends engaging in that hobby)
add button (displays value in dropdownlist and textbox in a table)
table (Hobby and daysAWeek will be shown here, with a delete icon to delete it)
submit button(saves hobby & days a week & username into database)
View hobby page
Displays user's hobby & days a week in a table.
Thanks for helping! And please provide simple and bare minimum coding as i am new!
Well, nobody posted an answer but my question was answered in the comments so..
Start by adding a 3rd table with UserId and HobbyId – Dagon
You're storing the relationship between, not a relationship. So think of it like you have two things and you want to remember that they relate. Thus, a table with two columns, one with an identifier of one part, the other with identifier (ID) of the other part. Pull them together with the data about each part, you have information. Hence, you've stored the relationship. It's like metadata, really. It's usually pretty efficient. - Jared Farrish
Thanks guys!