Ваш подход заключается в попытке присвоить несколько значений полю «ItemId», что приведет к проблемам, с которыми вы сталкиваетесь.Если бы я увидел «9500» в этом поле, как бы я узнал, что это значит?
Я бы предложил сбросить поле ItemId и создать таблицы «переходов» между Голосами и другими объектами.
Например, ваши лица:
+-----------+
| Articles |
+-----------+
| ArticleId | PK
| ~ snip ~ |
+-----------+
+-----------+
| Posts |
+-----------+
| PostId | PK
| ~ snip ~ |
+-----------+
... и т. Д. *
Таблица ваших голосов:
+-----------+
| Votes |
+-----------+
| VoteId | PK
| ~ snip ~ |
+-----------+
Ваши таблицы "пешеходного перехода":
+--------------+
| ArticleVotes |
+--------------+
| ArticleId | PK, FK to Articles
| VoteId | PK, FK to Votes
+--------------+
+--------------+
| PostVotes |
+--------------+
| PostId | PK, FK to Posts
| VoteId | PK, FK to Votes
+--------------+
Обратите внимание, что в таблицах пешеходного перехода вы должны создать составной первичный ключ, состоящий из обеих ссылок FK на соответствующие объекты, что обеспечит уникальность.
По моему опыту, этосоответствующий нормализованный подход к домену, который вы описываете.
В запросах, чтобы получить голоса за статьи (например), просто ВНУТРЕННЕЕ СОЕДИНЕНИЕ статей через ArticleVotes to Votes.Чтобы получить все голоса, просто запросите голоса.
Кроме того, я бы предложил создать таблицу IPAddresses и FKing к ней в таблице голосов, чтобы уменьшить избыточность.