Русское сообщество разработки на PHP-фреймворке Laravel.
Ты не вошёл. Вход тут.
Страницы 1
все привет!
есть три ресурса:
- способы оплаты
- регионы оплаты
- пользователи
у каждого способа оплаты может быть несколько регионов.
у каждого пользователя может быть несколько сайтов, несколько способов оплаты и несколько регионов этого способа оплаты (не все регионы!)
у каждого сайта может быть несколько способов оплаты и несколько регионов - из тех что доступны пользователю!
получается такая структура таблиц:
таблица methods (способы оплаты)
- id
- name
таблица regions (регионы оплаты):
- id
- name
таблица method_region (регионы способа оплаты - pivot)
- method_id
- region_id
таблица users (пользователи):
- id
- name
таблица user_method (способы оплаты пользователя - pivot):
- user_id
- method_id
таблица user_region (регионы оплаты пользователя для конкретного метода - pivot):
- user_id
- region_id
- method_id
сложно работать с такой структурой и поэтому у меня два вопроса:
- верна ли это струкрута базы?
- если да, то как строить запросы через Eloquent?
и если получить регионы способа оплыты просто:
Method::find($method_id)->regions;
то для получения способов оплаты пользователя
да еще и с регионами этих способов оплаты,
доступными для этого пользователя:
User::find($user_id)->methods()->user_regions($user_id)->get();
в модели метод user_regions() прописан вот так:
/**
* Регионы способа оплаты конкретно клиента.
*
* @param int @user_id
* @return relation
*/
public function scopeUserRegions($query, $user_id)
{
return $query->with(['user_regions' => function ($q) use ($user_id)
{
$q->wherePivot('user_id', $user_id);
}]);
}
/**
* Регионы способа оплаты у клиентов.
*
* @return relation
*/
public function user_regions()
{
return $this->belongsToMany('App\Region', 'user_region');
}
в принципе этот подход работает нормально, но мне кажется что можно сделать лушче.
что скажете господа?
там в начале вопроса про сайты идет речь, но код для них я убрал, потому что там такая же система получается как и для пользователя.
на мой взгляд решение вполне рабочее, другое дело что задача поставлена как-то не очень. по-моему доступность регионов и методов пользователю должна определяться как-то автоматически через промежуточную модель, а не вручную, через добавление связи в специальную пивот-таблицу. в частности связь с регионом, который определяет доступность методов оплаты: регион — это свойство пользователя или сайта? если сайта, то пользователю не нужна связь ни с регионами ни с методами оплаты, методы будут определяться отдельными сайтами. если пользователя, то зачем пользователю несколько регионов?
вообще мне кажется ограничивать какими-либо условиями, как пользователь может расстаться с деньгами — неправильно. надо наоборот, помогать пользователю отдать деньги любыми возможными способами.
и потом, если количество методов небольшое, то возможно их вообще не надо держать в отдельной таблице. сериализуй массив в json и сохрани в текстовом поле, а обрабатывай уже в бизнес-логике приложения. для малых наборов данных это вполне эффективно. кроме того если используется постгресс, у него есть замечательный тип полей ARRAY, который прекрасно поддерживается элоквентом.
Не в сети
Страницы 1