Повторное использование кода для лайков

[musaev.haybulla]

Ув. разработчики, вопрос, как мне кажется, из серии сотню раз решенных, но я это решение найти пока не смог.

На сайте, который сейчас пишу, в двух местах используются лайки - лайк объекта (дом, кафе, магазин) и лайк комментария (как на ютубе, к примеру).
Лайки ставить могут только зарегистрированные в системе пользователи.

Пока по архитектуре получается, что надо использовать отдельные таблицы для этих лайков в MySQL. Да и код дублировать, получается.
Но ведь, как мне кажется, это самый что ни на есть случай для иной архитектуры, подразумевающей отсутствие дублирования.
Например, сделать одну таблицу лайков и один класс, обрабатывающий эту таблицу. Но как там организовать связность - ума не приложу.

Не подскажете, как по-умному можно подобное реализовать?..

 

[Andkorol]

Указывать в таблице тип лайка для каждой записи (object/comment, 1/2, etc).

 

[keltanas]

Но ведь, как мне кажется, это самый что ни на есть случай для иной архитектуры, подразумевающей отсутствие дублирования.

Иной? А сейчас у тебя какая архитектура? Код на гитхаб, ссылку в студию

Например, сделать одну таблицу лайков и один класс, обрабатывающий эту таблицу. Но как там организовать связность - ума не приложу.

А сколько у тебя лайков планируется в этой таблице хранить?

 

[musaev.haybulla]

Кода пока нет)))
Обрисую на словах:

Есть место - дом, кафе, магазин или другой какой, его можно будет в системе комментировать пользователями системы. Помимо комментария, которых можно выставить хоть сотню одному пользователю, можно поставить лайк или дислайк этому месту. Он только 1 от 1 пользователя для 1 места. И то же самое можно по отношению к комментарию - можно комментить его сколько вздумается, но лайк поставить можно только 1 для 1 пользователя по отношению к 1 комментарию.

ПОка вижу такую таблицу БД:

places: {place_id, name, type}
users: {user_id, name}
like_places: {like_place_id, user_id, place_id, like}
comments: {comment_id, text, date, place_id, user_id, parrent_id}
like_comments: {like_comment_id, comment_id, user_id, like}

(Это набросок)

Вот и получается, что like_places и like_comments - близнецы, в своем роде. Разница лишь в том, что один в качестве одного из внешних ключей использует какое-то место, другой - какой-то комментарий.
Разумно предположить след. решение - сделать тип лайка.

1 - соответствует place_id,
2 - соответствует comment_id.

Но решение мне кажется "кривым", не универсальным, как костыль, что ли.
Нет ли изящней решения?..

 

[hell0w0rd]

Создаешь таблицу лайков и на нее строишь связи у объектов, которые можно лайкать, в чем проблема?
Если юзается орм - можно создать базовую likeable сущность и от нее наследоваться)

 

[keltanas]

Может лучше Redis Sets посмотреть как работают?

Чтобы понять, куда копать со структурой классов, расскажи, на чем сайт будет? Фреймворк какой, или свой велосипед?

 

[Adelf]

необязательно одну таблицу. можно для каждой сущности свою таблицу лайков. и дублирования в коде можно избежать. В итоге получится лишь небольшое дублирование в базе. Которое легко пережить.

Когда есть выбор где делать магию, в базе или в коде - я выбираю код. В базе должно быть все строго и четко. Яв своё время неплохо обломался с такими вот типизированными сущностями.Проблем будет больше, чем экономии.