Comments on an Article

Ideas for Trying and Implementation to achieve the above

[mvaz]

Dear all

As in the past, I am only trying to find ways to do things, not the actual scripts or coding itself, which I request you to review when I have my own.

On one of the sites that I have, I have a page which pulls out data from a table in mysql, and lists the contents.

I also have a form which I place at the bottom of this page, so that viewers can comment on this article/news item.

I now want to list these comments immediately after the article.

Now what I am looking for is, how can I achieve this? Do you suggest I store every comment (of course, after sanitising the user input) in a separate table, along with article id or title to this table? If I did this, would it be too taxing for the server to pull out the data from two tables at one time, resulting in under par performance?

I am looking for your various suggestions so I can try and implement the best suitable for the purpose.

Many thanks in advance - Melwyn

[omoutop]

The only possible way to do this (as far as i know), without reloading your article page, is by using AJAX. There are countless tutorials on this out there and you can find what you seek easy.
The main concept is that not all of the page gets refreshed/reloaded, but rather a portion of your screen, usually inside a <div></div> holder.
As of the performance, worry not, as long as your comments are just that, comments, and not a 3-page booklet

[Readie]

There are no performance issues with retrieving data from 2 tables that I am aware of, and I know that PHPBB forums store forum posts in the method you have described.

When saving your comments by the way: make sure you record the date and time (down to the milisecond - you never know how close 2 users are going to post) so that you can sort them accordingly.

[CyBerAliEn]

As noted... if you want the new comment to appear IMMEDIATELY after it being posted, without fully reloading the page, you'll need to do AJAX. I would suggest that this is not necessary. Just implement in the plain-old HTML+PHP manner. You can implement Javascript (AJAX) seamlessly later if you desire.


Now... as for handling your comment data:
No; using 2 tables (or more) is not a significant performance killer. You can do very advanced queries with SQL (a la mySQL database engine, for example) that are effectively "quick", all things considered. You really only need to worry about specific performance hits once you reach a high threshold of activity. The vast majority of sites don't experience this, so you're likely fine regarding performance. So don't worry!

Second point: Do not worry about doing multiple tables! You want your database design to be sound... what is often called normalized in the industry and academics. This is a huge issue with a lot of PHP projects/scripts/etc because the DB is often setup by a programmer/coder (not someone with experience/skills in information systems or database design). Boil-down philosophy: Having multiple tables is a much better design than a single table with everything shoved in it.

From what I gather, you should have two tables:
(1) articles
(2) comments

Your articles should have a unique identifier (primary key) for each article. I'll assume this is a field "articleid". I imagine you have the rest of the table already covered (title of article, article content, article author, etc).

Now, for comments, I propose a schema similar to:
*commentid - integer - auto increment - primary key
*articleid - reference article id from article table - foreign key
*name - name of person posting comment
*email - email of person posting comment
*url - url of person posting comment
*comment - comment of person for article
*ip - IP address of person posting
*posted - UNIX timestamp of when article posted

This is a very general structure. Some of these are optional; for example: name, email, url <--- you don't have to ask for this info or store such info. You can get by with just 'comment'. The other fields are all mostly for utility... you need an ID to reference, you need to reference the comment back to the article, you need to know when it was posted, etc.

Use a simple integer/auto-increment as the comment ID; this way the DB handles generating a unique ID for you. Likewise, I prefer using a UNIX timestamp for "times" because it is very easy to sort by and to manipulate later (both with PHP and with mySQL).


Handling Comments
For posting comments, just use a simple HTML form to submit the comment. Sanitize user input (against mySQL injection; clean of HTML if you want; trim; etc). Then insert and store the comment in the new table.

For displaying comments, just add code below the article that queries the comments table looking for comments that are associated to the article. You probably want to order them by 'posted' (ASC or DESC depending on your preference). Then just display each comment as wanted. If no comments are retrieved, you can display a 'no comments' message. Etc.

[mvaz]

A Big thank you to all who commented and provided valid insight into addressing this issue. A special thanks to CyberAlien for providing and suggesting a structure for this project. Like always, you guys have been brilliant, and this is why, whenever I have any issues or need references I am here and never ever felt let down. Once gain, thank you!