Нужна ли общая таблица?

Question

[ModeRa]

Схема

Есть таблицы:
Users (Пользователи)
-Id

Services (услуга, которую может выполнить пользователь)
-Id
-User (многие к одному)

Requests (запрос пользователя на услугу, которую требуется выполнить для него )
-Id
-User (многие к одному)

Responses (Отклики пользователя на предоставление услуги или на запрос)
-Id
-RespondedUser
-RequestedUser
-Service
-Request

В таблице Responses может быть заполнено только одно поле из Service и Request. Подозреваю, что ведение и того и того - неправильно. Т.е. хотелось бы иметь только одну колонку. Нужна ли здесь какая-то общая таблица для Services и Requests? Или стоит разделить таблицу Responses на две? Отдельно для Services и отдельно Requests?

Comments

[ModeRa]

А что, если добавить общую таблицу.

CommonTable
-Id

Services
-Id
-CommonTableId (многие к одному)
-User (многие к одному)

Request
-Id
-CommonTableId (многие к одному)
-User (многие к одному)

Тогда в Response будет одна колонка.
Responses (Отклики пользователя на предоставление услуги или на запрос)
-Id
-RespondedUser
-RequestedUser
-CommonTableId (многие к одному)

Покритикуйте решение, пожалуйста. Кажется есть какая-то избыточность здесь.

Answer 1

[FernandoErrNando]

Если я правильно понял, то ты хочешь сделать полиморфные связи. Но у тебя в любом случае не получится обойтись 1 колонкой, там используются 2 колонки (entity_id, entity_type), зато это универсальное решение, если у тебя появится ещё какая-нибудь сущность, на которую можно будет откликаться, то у тебя будет по прежнему 2 колонки.

Минусы: более сложные запросы, невозномность постановки констрейтов, т.е. уровень контроля целостности в данном случае ложится на уровень приложения

Comments

[ModeRa]

Правильно ли я понимаю, что альтернативой будет разделение Responses для каждой сущности отдельно?
Т.е. у меня будут ServiceResponses и RequestResponses. Тогда и минусов можно избежать?

Answer 2

[Vitsliputsli]

По требованиям описанным в задаче:

запросы на исполнение услуги

Users (Пользователи)
-Id

Services (услуги)
-Id

UserServices(услуга, которую может выполнить пользователь)
-Id
-User.Id

Requests (запрос пользователя на услугу, которую требуется выполнить для него )
-Id
-Users.Id (запрашивающий пользователь)
-Services.Id (запрашиваемая услуга)

Responses (Отклики пользователя на предоставление услуги или на запрос)
-Users.Id (откликнувшийся пользователь)
-Requests.Id (запрос, на который отклкинулся)

По требованиям, с учетом комментария "Пользователь может как откликнуться на заказ, так и выбрать исполнителя, не создавая свой заказ".

поиск исполнителья или нанимателя

Users (Пользователи)
-Id

Services (услуги)
-Id

UserServices(услуга, которую может выполнить пользователь)
-Id
-User.Id

Requests (запрос пользователя на услугу, которую требуется выполнить для него )
-Id
-Users.Id (запрашивающий пользователь)
-Services.Id (запрашиваемая услуга)
-Status (статус: открыт или завершен)

Deals (Заключенная сделка)
-Users.Id (пользователь-наниматель)
-Users.Id (пользователь-исполнитель)
-Services.Id (услуга для исполнения)