Amr Mohammad Rashad Ответов: 1

Как хранить полиморфные связанные модели


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

class Coordinator extends Model
{
    protected $fillable= ['userid', ...];
    ...

    public function user()
    {
        return $this->morphOne(User::class, 'userable');
    }
}


class User extends Model
{
    ...

    public function userable()
    {
        return $this->morphTo();
    }
}


class CreateUsersTable extends Migration
{
    public function up()
    {
        $table->bigIncrements('id');
        ...
        $table->morphs('userable');
    }
}


class CreateCoordinatorsTable extends Migration
{
    public function up()
    {
        $table->bigIncrements('coordid');
        ...
       $table->foreign('userid')->references('ID')->on('wp_users')->onDelete('cascade');
    }
}


После миграции я заметил, что столбцы userable_type и userable_id не допускают null. Как я могу создать сущность координатора с связанной с ней сущностью пользователя?

Что я уже пробовал:

Теперь я изменил столбцы nullability, чтобы разрешить null и хранить пользовательскую модель, а затем получить ее идентификатор и использовать его при хранении координатора.

Richard MacCutchan

Почему бы просто не создать единую "пользовательскую" модель, содержащую всю информацию? Одним из элементов контента должен быть флаг или флаги, указывающие тип пользователя (обычный пользователь, администратор, специальный пользователь и т. д.).

Dave Kreskowiak

Вы также можете просто иметь один пользовательский объект, содержащий всю общую информацию для каждого пользователя, а затем "мешок свойств" для пользовательских материалов для каждого пользователя. Это будет просто коллекция пар ключ/значение.

Amr Mohammad Rashad

Я использую PHP специально для его MVC-фреймворка, то есть laravel и его ORM-фреймворк eloquent, и я использую ORM для хранения/извлечения, и, насколько мне известно, он не работает таким образом

Dave Kreskowiak

М-м-м... Вы только что сказали, что ваш ORM не может обрабатывать отношения мастер/деталь, такие как заказ клиента или счет-фактура. Это просто невозможно для Орма, который стоит своего веса.

Ты слишком много думаешь и слишком все усложняешь. В итоге вы получите два стола. Один для пользователей и один для UserProperties, где вы храните свои индивидуальные данные о свойствах. Это данные, которые отображаются не как определенное свойство в классе, а как набор "свободных" свойств.

Amr Mohammad Rashad

The case not a simple master\detail because eloquent definitely handle this but what I am talking about many tables\models one for each type (i.e., coordinator, hospital, shipper etc.) each has its own id column and a user table\model has columns stores id value and a type value according to the type that user entity relates to. For example, I stored a coordinator within a coordinator table with an id value of 10 then within the user table a column called userable_id will have the value 10 and a column called userable_type will have the value 'coordinator' if I stored a hospital within the hospital table with an id value of 5 then within the user table a column called userable_id will have the value 5 and a column called userable_type will have the value 'hospital'...

Dave Kreskowiak

Я сказал свое слово. Ты слишком много думаешь и слишком все усложняешь. Мир вышел.

Amr Mohammad Rashad

В любом случае, спасибо за ваше время и внимание!

1 Ответов

Рейтинг:
12

Amr Mohammad Rashad

Я получил его после поисков Что Laravel один-ко-многим полиморфные отношения - создавать записи.

Идея не такая, как я думал вначале. Когда я использовал

$table->morphs('userable');
the user table had two columns, userable_id and userable_type, and each allows no null by default and by ORM convention and I was thinking that they consider the user table is the master and other tables (i.e., coordinator, educator, shipper etc.) each as the detail table. According to this initial wrong understanding I was adding a userid column at each table to store the related user id for each specific user type and I was wondering how I am going to save the user that needs the userable_id and userable_type to be filled by saving the specific user first to get its id that will be provided to the user's userable_id the case resembles a deadlock situation as each table needs a piece of information that will be known after storing data on each to be able to save data to each table, wired!!!.

Однако, когда я прочитал статью по приведенной выше ссылке, я понял, что она рассматривает таблицу противоположным образом, в отличие от моего мышления (т. е. координатор, Грузоотправитель и т. д. являются мастерами, а пользовательская таблица-деталью). Это для парней, которые используют модели напрямую, но для тех, кто использует пакет репозитория, это немного сложно, и вам нужно сделать дополнительную работу...