Отображение гибернации: один столбец в несколько таблиц

У меня есть вопрос «передовой практики» для сценария.

Сценарий: Несколько сущностей в БД, например, Document, BlogPost, Wiki, могут совместно использоваться отдельными лицами. Вместо создания общей таблицы для каждого объекта создается одна общая таблица. Проблема в том, как сопоставить общую таблицу с разными объектами?

У меня есть три варианта, посоветуйте, пожалуйста, какой вариант лучше, и есть ли лучший вариант.

Вариант1: Создать общие ресурсы таблицы как:

SHARES  
id (unique)
entityId (non DB enforced FK to DOCUMENTS, WIKIS, POSTS etc.)
entityType
sharedBy
sharedWith
sharedDate

Здесь entityId будет FK для documentId, wikiId, postId и т. Д. И т. Д. И entityType будет идентифицировать тип entityId.

Это вызывает проблемы при моделировании Hibernate при создании сопоставления общего ресурса с сущностями, например share.getDocument () или share.getWiki () и т. Д.

Вариант 2: Создайте таблицу Shares, которая содержит только информацию об общем ресурсе, а затем создайте таблицы разрешения, которые привяжут общий ресурс к объекту.

SHARES
id(PK)
sharedBy
sharedWith
sharedDate
shareType (helper field for searches)

SHARES_DOCUMENTS
share_id (unique ID and FK, one to one with SHARES)
document_id (FK to DOCUMENTS)

SHARES_POST
share_id (unique ID and FK, one to one with SHARES)
post_id (FK to POSTS)

more share tables here.

Итак, в спящем режиме общий ресурс может иметь один к одному для каждого из типов общих ресурсов (например, share.getDocument (), share.getPost () и shareType будет определять, какая связь является «активной»)

Вариант 3 Аналогично варианту 1, но вместо идентификатора объекта создайте отдельные столбцы

SHARES
id (unique ID)
documentId (FK to DOCUMENTS, nullable)
postId (FK to POSTS, nullable)
wikiId (FK to WIKIS, nullable)
sharedBy
sharedWith
sharedDate
sharedType

. Здесь каждый столбец может быть сопоставлен с соответствующим объектом, но они допускают значение NULL. sharedType может определить, какое отношение является «активным».

Итак, вопрос в том, какая практика лучше всего, как с точки зрения базы данных, так и с точки зрения гибернации (и, в конечном итоге, запросов, с точки зрения производительности).

Спасибо М. Скорее