Using a db vote table for many arguments tables

I'm trying to understand if it's right to use one table for votes for more than one argument:

table_votes
id | vote (±1) | id_user | timestamp | argument_type | argument_id


table_photos // could be argument_type = 1
id | photo_file | photo_name | etc.    


table_house // could be argument_type = 2
id | house_name | etc.

My problem starts if I'd like to use it to rename e table value, for example house names, I could create a table to change suggestions based on users agreement, for example 3 votes on 5 total.

table_house_name_suggestion // could be argument_type = 3
id | new_house_name | old_house_name | id_user | timestamp | locked // when votes are enough

So, could this be a right way or I'm losing something important which guide me to use a vote table for every argument or should I think to开发者_开发问答 create a vote table for every argument?

---

Create a table that knows about all arguments (PK and FK denote primary and foreign keys):

vote  { vote_id PK, vote, user_id, timestamp, arg_id FK(arg.arg_id) }
arg   { arg_id PK }
photo { photo_id PK FK(arg.arg_id), photo_file, photo_name, ... }
house { house_id PK FK(arg.arg_id), house_name, ... }

Note that photo_id and house_id are actually arg_ids. The only potential inconsistency is that a single arg could be both a photo and a house, so the business layer would have to ensure that that can never happen.

Now, I'm a little confused about the second half of the question. The argument_type refers to whether it's a photo or a house, right? If so, argument_type = 3 suggests that house_name_suggestion is just another type of thing you can vote on. It is of course, closely related to the house table, but from the perspective of voting, I'd say that this is irrelevant. If so, then you simply add a new table to the mix:

house_name_suggestion { house_name_suggestion_id PK FK(arg.arg_id),
                        house_id FK(arg.arg_id), new_house_name, old_house_name, ... }

Note, however, that I've added a house_id column. While I'm not 100% sure, I think you were using the id column to double up as a primary key and as a reference to the house table, which would have meant that each house could only have one house-name suggestion.

Side note: You have a mixture of plural and singular nouns in your table names. I strongly suggest sticking to singular. Also, the table_ prefix adds very little value, and is a pain to work with. Don't bother with it.