I have a Comment model that has a "ownerId" which is the person who created it and the users have the option to like/dislike a comment and to keep track of how already liked/disliked a comment is. I think that I need a list of foreign keys. There is also the option to make another table with comment id and user id but isn't this worse?

CodePudding user response：

As a few stated?

DO NOT try and munge this up by storing multiple values in one column. It seems like a great idea, but you REALLY lose any and all abilities to allow the beautiful thing we have called a relational database.

Bite the bullet - grab that cup of coffee, and do this right.

So, create a new table. That table is a list of voted comments. MUCH better is you can now use sql to:

• Get the current user voted (up or down) - easy to let them change.

• Get the total number of votes (up or down) with sql query

• Easy add and extend the design - say date when up/down voted great statics.

The above list could be longer - but really, just even when you display the comments, you no doubt want to show the CURRENT users choice (or maybe they don't have a choice, but those operations will be ONE record, and you can change the up vote, the down vote and as noted, maybe even save the date of when the user did this.

It is going to be a simple table. Say like this:

I mean, just to count the up-votes, just to edit save?

All this will become plane jane data operations.

You try and stuff into one column all those id? Now you have to parse out, fetch the one id - maybe not found. And then how about a simple query to show up votes and down votes? Again, messy.

If this was a xml, or even a json database (no-sql), then maybe ok.

But, if this is a sql database? Then do this the right way. I love json or even xml types of databases, but in sql land?

Do as they do in Rome, and in this case?

Do as they do in the Country of sql land!