AK
Size: a a a
2021 March 29
BB
а, может быть речь про то, что надо сделать |raw еще, чтобы кавычки в " не превращались
Спасибо большое!!!!!!
BB
я не думал что после json_encode надо в | raw сворачивать
ЕУ
и все же по мне это лишняя таблица и нестандартный кейс связи. Эту задачу легко решить на стандартных связях, в данном случае MtM+MtO
Мы делали у себя так:
Вместо Department у них Company например
Department:
id
name
Position:
id
permissions: []
User:
id
full_name
UserPosition:
user_id
position_id
department_id
is_active
active_date_from
active_date_to
Вместо Department у них Company например
CV
Мы делали у себя так:
Вместо Department у них Company например
Department:
id
name
Position:
id
permissions: []
User:
id
full_name
UserPosition:
user_id
position_id
department_id
is_active
active_date_from
active_date_to
Вместо Department у них Company например
а, ну тут у вас целая сущность на должность
✨
по моему это выглядит как отдельная сущность mtm, которая хранила бы для пользователя должность, т.о. получим должность юзера, которая связана с компанией, которая имеет определенные должности
AK
а, ну тут у вас целая сущность на должность
так и предлагалось с самого начала
✨
Мы делали у себя так:
Вместо Department у них Company например
Department:
id
name
Position:
id
permissions: []
User:
id
full_name
UserPosition:
user_id
position_id
department_id
is_active
active_date_from
active_date_to
Вместо Department у них Company например
ну да, что-то вроде того
✨
нужно только поработать с формой с динамическим изменением
ЕУ
например, наш заказчик - большая организация, где куча департаментов. каждый сотрудник может быть в разных позициях в разных департаментах. и должен иметь доступ только к тем документам и действиям, которые относятся к его департаментам согласно его должности
CV
так и предлагалось с самого начала
вопрос надо ли оно? Если нужны эти доп данные, то безусловно хороший подход. Если нет, то я бы не плодил лишних сущностей и обошелся бы 2мя типовыми связями. Но подход через сущность-связь бесспорно имеет место быть
AK
вопрос надо ли оно? Если нужны эти доп данные, то безусловно хороший подход. Если нет, то я бы не плодил лишних сущностей и обошелся бы 2мя типовыми связями. Но подход через сущность-связь бесспорно имеет место быть
не могу найти в переписке про какие 2 типовые связи вы говорите. user -> должность, должность -> company?
CV
не могу найти в переписке про какие 2 типовые связи вы говорите. user -> должность, должность -> company?
Юзер-роль МтМ, компания-роль ОтМ
G
Мы делали у себя так:
Вместо Department у них Company например
Department:
id
name
Position:
id
permissions: []
User:
id
full_name
UserPosition:
user_id
position_id
department_id
is_active
active_date_from
active_date_to
Вместо Department у них Company например
как по мне, такой подход лучше
И
Юзер-роль МтМ, компания-роль ОтМ
Это +1 джоин без foriggen
AN
вопрос надо ли оно? Если нужны эти доп данные, то безусловно хороший подход. Если нет, то я бы не плодил лишних сущностей и обошелся бы 2мя типовыми связями. Но подход через сущность-связь бесспорно имеет место быть
Ну да иногда данные принадлежат самой связи, а не одной или другой модели