Your first option seems the best to me:
- A second table Comments with Content id and Comment
Let's look at why the other options are less optimal.
Your second option:
- One new table for each Content, to store the comments(advantage : no need to store content id again for each comment)
Now your code has to specify a different table each time you want to read comments for a different content type:
if ($contentType = 1) then $sqlPart = 'table1';
elseif ($contentType = 2) then $sqlPart = 'table2';
else $sqlPart = 'table3';
$sql = 'select comment from ' + $sqlPart;
This is not sustainable. Your content table contains data - your system can add new data, then you have to re-write your program code to account for the new data (as well as create a new comments table for the new content type).
Your third option:
- A Text/String column, using a certain separator to seperate comments & comment infos
Now you have to do a whole lot of processing to get comments:
$comments = getCommentsFromWideField();
$commentArray = split($comments);
Not only is this a lot of work - but how do you sort comments into time order? You have to encapsulate the comment timestamp into your wide string. Your super-super wide column is also not efficient within the database. How will you update a comment - extract all of the comments, break up the string into an array, somehow locate the one comment you want to edit, edit it, put the array back into a string and update your huge column. No thanks.
Your fourth option:
- Same as above, but using a BLOB
My response is same as above too.
There are good reasons why normalised databases are so popular - these include efficiency and ease of understanding relationships between data. With a dedicated table for comments you will be able to extend your data model easily in future, for example, to include new information about each comment record: time created; user who commented; upvotes; tags; etc.
Go with two tables: Content and Comments. Join them on the id that you have. Your future self will thank you.