Как брать теги только принадлежащие той модели?

Question

[abuamr]

posts
    id - integer
    name - string

videos
    id - integer
    name - string

tags
    id - integer
    name - string

taggables
    tag_id - integer
    taggable_id - integer
    taggable_type - string

Есть вот такая структура таблицы. Задача в том, чтоб при добавлении в таблицу videos в select вывели только tags которые относятся к videos.

Можно в tags добавить type и туда писать название таблицы и через query scopes фильтровать в каждой модели отдельно. Но есть ли другой способ легче сделать это ?

Comments

[Алексей Уколов]

Технически, при такой постановке, к видео нельзя будет добавить ни один тег, потому что изначально не будет привязано ни одного и селект всегда будет пуст. Такое решение выглядит странным, почему бы не добавить в саму модель тега доступные для неё типы сущностей?

[abuamr]

Алексей Уколов, Это простой пример, у меня 8 таблиц к которым нужно добавить тег, если для них делать отдельно tablename_tag таблицу, это еще 8 дополнительных таблиц

[abuamr]

Алексей Уколов, Если есть другой способ готов к экспериментам

[Алексей Уколов]

Во-первых, «ещё 8 таблиц» — это не всегда плохо. Во-вторых, я уже предложил другой способ — экспериментируйте.

[abuamr]

Алексей Уколов, Это хард код. Лучше добавить в tags поле type и там хранить название таблицы

[Алексей Уколов]

почему бы не добавить в саму модель тега доступные для неё типы сущностей

Лучше добавить в tags поле type

Answer 1

[Александр Талалаев]

Так а в чём проблема, всё есть в документации, полиморф отношения:
https://laravel.com/docs/8.x/eloquent-relationship...

Comments

[abuamr]

То, что описал нету в документации.

Посмотрите этот пример с документации, просто нужно дополнить логику правильно

[Александр Талалаев]

abuamr, простите, не сразу понял вопрос.
Те вы хотите просто изначально хранить типы тегов?
Тогда да, в tags добавить поле type(может быть верно цифровое, но бы сделал строковое). Можно завести reference класс для хранения и расширения библиотеки типов, что-то вроде

<?php

namespace App\References;


class TagTypeReference
{
    public const TAG_TYPE_VIDEO = 'video'; //ну или цифра если числовое
    public const TAG_TYPE_POST = 'post';
    public const TAG_DEFAULT_TYPE = self::TAG_TYPE_VIDEO;
    public const TAG_TYPES = [
      self::TAG_TYPE_VIDEO ,
      self::TAG_TYPE_POST ,
    ];

Ну и потом да, можно через scope фильтровать. Доп таблицы не нужны, если у тебя не супер динамика(а раз у тебя разные таблицы видео и посты, то это так), и по мере необходимости расширять этот класс.

[Александр Талалаев]

Mellorn, сложно сразу и в целом говорить, так как общего плана целей и архитектуры мы не знаем. Может быть нужна единая точка поиска и сбора тегов, может не нужна. Можно/нельзя иметь много типов у тега и тп и тд. Слишком мало в постановке задачи данных чтобы решить. Изначально как мы видим всё было сделано под эту модель. Я подразумевал что у тегов может быть какая-либо единая логика действий и прочее и для удобства и меньшего числа одинакового кода из коробки удобнее так. Но конечно же много таблиц это вовсе не плохой вариант, ну стоит его боятся если он лучше отражает логику приложения.

[abuamr]

Александр Талалаев, Это было простим примером, чтоб понять суть многих ко многим реализуя через reference или через scope.

А сама задача состоит в том, что есть 7 таблиц (vendors, deliveries, clients, employees, owners, terminals, users) от куда можно войти в систему. Сейчас требуется автоматизировать статусы, чтоб после регистрации статус (есть таблица statuses) менялся, типа в модерации, заблокирован, требуется оплата и тд. Соответсвенно для каждой таблицы нужен свой статус.

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

[Алексей Уколов]

Имхо, лучше разделить. Никакого профита от объединения в одну сущность вы не получите, когда речь идёт о статусах — это слишком важная часть бизнес-логики обычно.

[abuamr]

Алексей Уколов, Хорошо, спасибо!