Im programming my own simple blog with comments in php and mysql. I have one database, and I have one table for posts, (called posts) and for each post I make I manually create a new table called comments1,comments2,comments3, etc. Each blog post has an id and when I retrieve the comments for a post I use a query like:
SELECT * FROM `comments".$id."`"
When I add user text to a comment I use:
htmlspecialchars(mysql_real_escape_string($_POST['name']));
Is this structure ok or is there a better way I'm missing?
Also, would creating a different database for comments be a better practice than grouping it with the posts database? Does having 2 dbconnect functions in one file slow down performance by a lot? And one last worry: how do i make absolutely sure that my php files aren't served to the user as plaintext, because then they could see db login info and such.
Thanks for the help.
No, this is TERRIBLE structure.
Make one comments table and store all comments in there, along with corresponding post_id.
Add an index on post_id and you'll be able to quickly get all comments for a given post.
Related
I want to add a new discussion area to my website in which users will be able to add topics and receive comments.
I thought I will add a new DB just for the topics and comments to avoid my main DB becoming very large.
But, I will need to connect to the main DB to retrieve user information, perform login processes and so on.
So, what should be better for my site's performance? and why?
1- Adding new tables in my main DB for topics and comments.
2- Adding a new DB just for the topics and make 2 DB connections.
Note: Please, focus on the general idea of the question not only this specific case.
I would say option 1.
It keeps your code more organized and your site doesn't have to load in and retrieve data from a second database. it's also easier to connect which user posted what. Large database shouldn't matter as long as you write your query in a proper way.
Add the tables to the same database.
The topics and comments tables have a relationship to your existing data (especially your users table, since you probably want to store which user started a topic or wrote a comment), and should therefor be in the same database.
You might even want to enforce the referential integrity of your database by making sure that every author_id in your topics and comments tables exists as a user_id in your users table. You can enforce this using foreign key constraints but, as far as I know, only if all tables are in the same database.
Here goes a very basic question.
Here is my stroll in trying to create a form for work:
I created the HTML form. Added some JavaScript to make it do some things I needed. Stylized it with CSS, wrote PHP code and created a Database (I had no idea of how to do it at first) for the entered data to be saved.
I didn't know how to do any of that, but in the past two weeks I've managed to make it exactly the way I needed, and I'm very pleased with myself. After a lot of work, the form perfectly sends the data to the database and displays it in the page after you hit submit, and also looks really good too.
The thing is... this that I am creating is an Activities Bank for us to use here at work (I teach English) and the page (base) I have created is only ONE of MANY that are needed in this data bank. Let me explain... Let's say the page I've created is the post and display of, say, Book3 Chapter1 Activities, and I need to have many other pages (which will be exact copies of this one).
My question is... will I have to create (actually, it's copy and paste) new databases/tables manually (which will be more than one hundred of them) or there is a way to automatize this process?
I mean, all the pages will share the same variables and the same form... the only different thing will be the title and the entered data, of course.
Will I have to create a database for each page? Or a new table for each page in the same database?
If you still don't understand what I need, here is how this is supposed to be:
Book1 has 40 chapters, so, 40 copies of the same form (which already works fine);
PLUS
Book2 that has 40 more chapters, etc.
Thanks in advance for any clarification.
Sorry if this is such a basic question, but if it isn't, if otherwise, what I wanna do is very complicated, I don't mind that I don't know much about all this and I will take the challenge, like I have, when I was making this form from scratch, without ever hearing about "databases". Any words of help are appreciated.
That isn't how databases or tables work. You should be creating a new row in one or more tables for each form submission. You should almost never be dynamically creating tables, and even less often databases.
It sounds like you want a books table, and a chapters table. Each row in the books table will have many rows in the chapters table "pointing" to it via foreign keys.
I think in your case your case two tables.in total.
As you have already added one, you need another one, where the first one will contain the common data with a primary key column and the other table will keep the primary key of the first table and the data which occurs in multiple. Then later you needs to join (Sql join)rotatable to get your data.
I am working on a small project where a client would like to have a custom comment system to be shared within the internal network of there company. The logic is something like Google+, Facebook (other?) Where a user will make a Post and have the ability to choose people to share it with where the default (none) will go to everyone in that persons list.
My question is what is the best way to build up a table to store posts where it could have all or select people as the able viewers of said post. I guess my biggest issue is wrapping my head around the logic of it at the moment. Do I have multiple rows per post each with an id of the user(s) able to see said post, should I have a column on a single row for the post where I store an array or object of people able to view the post, I am open to suggestions. I haven't started working on it as of yet. So I am ultimately looking for advice on a good way to build the table that would support sound query logic, that won't cost me over head on either multiple queries or multiple rows I don't need. Don't want to begin without figuring something out as I don't want to box myself into something that will be harder to back out of in the long run.
What you are proposing is a one-to-many relationship. There is a ton of information about db relationships on the internet. Each Post could have Many people that would be allowed to use it. So you would have a posts table and a users table and a users_post table. The users post table would contain a post_id and a user_id. You would then have to check if the user could view the post through this relationship.
You could also put the users in groups, which would simplify this.
You should never store multiple values in an array in one column of the db.
Im making an application where users are able to comment on a lot of things, like blog posts, uploaded songs, pictures and so on.
Is it better to store ALL comments in one table where you have a column that points to what the comment was posted, e.g. blog, picture etc.
Or is it better to store them in separate tables, like "blogcomments" table, "picturecomments" table etc? Say for a site with 10000 plus users?
Thanks
If all comments have the same data being stored (e.g. comment content, user who posted the comment, etc), then it would make the post sense to keep them all in a single table. If they have different formats, then put them in separate tables.
In my opinion the first approach is the better one. Infact, this way, you can add (or remove) type(s) of comment (I mean post comment, blog comment and so on) without adding or deleting every time a table. I think this it is a more scalable solution.
I'm trying to make a facebook style news feed on my webpage that combines user input from multiple tables into a feed.
Would the best way to approach this be:
(1) Using mySQL Join Queries
(2) Using mySQL single queries from multiple tables into an Array.
(3) Another way?
Thanks.
Edit:
The structure of my Databases are as follows:
1 User (Table: User)
Mutliple Blogs per user (Table: Blog)
Mutliple Content Upload per user (Table: Content)
What I am trying to achieve is a query that will collect the defined users ID's blog post and content uploads and display them in chronological order.
Thanks for the replies!
This is difficult to answer without knowing anything about your database schema (consider editing your question to add some details), but you may wish to consider creating a View that you could then retrieve and present your news feed from with a single, simple query.
If there is going to be a lot of data it is good to have a separate table that holds your "feed". That way, you don't have a lot of overhead each time you do your query.