I'm assuming a normal blog here, where each comment must relate to one and only one blog (article?). In that case, the second setup (where you use the article ID as a foreign key) is far superior.

Think about what it would take to find all comments for a given article for each method. Let's say you're working with the article whose ID is 1. In the first scenario you would have:

SELECT * FROM `comments` WHERE `id` IN (SELECT `cid` FROM `bid_cid` WHERE `bid` = 1);

In the second scenario you would have:

SELECT * FROM `comments` WHERE `bid` = 1;

The second is much simpler, much more efficient, and much more normalized.

I disagree with PettyRider… I can't remember ever seeing an argument for using a join table unless you're modeling a many-to-many relationship. All one-to-many relationships should be modeled using a foreign key unless there's an extremely compelling reason not to do so.

I don't mean to keep harping on the same thing, but, even if you want to allow people to reply to comments, you don't need an associative table. Simply add a column in your comments table to store the parent comment ID. If the parent comment ID is null, you know the comment was in reply to the article itself, not another comment. Similarly, if the comment has a parent comment ID, you know it was in reply to another comment, not the article itself.

I'm just glad people are asking questions about something other than design. I know this is a design oriented site, but questions about query efficiency are important too.