Коллеги всем привет ) Задал вопрос в чат новичков, сорян, если

кому то 2 раза замылит глаза, но тут вопрос наверное больше не к новичкам ))буду признателен за мнения)


Есть заказ у него есть связи с сущностями БД метод доставки (del), статус ((st) и метод оплаты (pay)

Соответственно фронт отправляет айдишки этих сущностей

Сейчас возник спор как правильно создавать заказ
1. Методом create
Order::create([
Del = 1,
Pay = 1,
St = 1
])
Впринципе комфортно, доводы против - привязаны к айдишкам, не видим явных и обязательных связей для заказа
2.
St = Status::find(1)
Del = Delivery::find(1)
Pay = Payment::find(1)

И потом для каждой сущности
Order->relation()->associate(entity)
Order->save()
Доводы за - все методы связи сущностей можно вынести в метод модели и тогда будем видеть обязательные связи, без которых модель не может быть создана. Доводы против - запросы в бд на извлечение сущностей для связи, не известно как скажется под нагрузкой

Кто что думает, как лучше делать создание ?)

@Adelf32 он вот про это, вангую

Почему фронт управляет статусом? Паттерн стейт машина знаем? :)

Какой бы ты токсичный человек не был, твое мнение, Артем, по вопросу тоже очень интересно)

Потому что на фронте происходит выбор разных значений

А должно быть инкапсулировано в БЛ, ИМХО. Пусть с фронта летит пользовательский ввод и обрабатывается контроллером

Тогда приходим к тому, чтобы извлекать и использовать метод 2)

Опасаетесь за производительность?

Ну меня именно эта часть беспокоит в большей степени Второе, код будет выглядеть значительно хуже в плане читаемости)

Извлекать полюбасу)) как минимум- проверять наличие в бд- иначе с фронта прилетит всякое разное)) find работает быстро, так что сервер это даже и не заметит.

Спасибо ) Мне уже объяснили что фронт отвечает в таком случае за БЛ, что не есть хорошо)

ну, фронт по умолчанию считается "дырявым"))) т.е. все валидации полей формы на фронте - они не для безопасности, а для улучшения юзабилити, чтобы юзер не тыкал по 10 раз мышью или пальцем в экран)))

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

да, запросы по первичному ключу оч быстрые :-) я бы сказал - САМЫЕ быстрые))

Тогда немного глубже пойду с вопросом ) А если мы за правило возьмём такую предварительную валидацию связей перед записью, то какой смысл во внешних ключах?) Или по ним тоже индекс вешается для скорости поиска ?

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

например, чтобы не удалить то, что не должно быть удалено

Ясно )

Понял ) спс )

Я просто везде каскадное удаление почти вешаю)) так что замечание такое, буду пересматривать свои взгляды в этом вопросе )

понимаешь, ключи - это НЕ бесплатно для производительности )) будь иначе - на КАЖДОЕ поле просто вешали бы индексы по дефолту и всё )) т.е. тут всегда поиск компромисса, между тем и этим)

это не бесплатно по размеру БД вроде? Как с производительностью связано?

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

Как говорится - гетмикротайм вам в руки))) и по завершении можно пилить статью на Хабр ))