Обычный оператор echo решит вашу проблему.
Ну или скорее использование этого значения в каком-то коде.
Вы же не для того чтобы вывести это значение передавали, а чтобы записать куда-то?
Поскольку вы по какой-то неизвестной причине не показали, как именно вы достаете значение ключа, то никто в мире не сможет ответить на вопрос, "почему вы не можете это сделать"
Еще раз. Делать вставку одним запросом - это не решение.
Там ускорение будет в единицы процентов.
Кроме того, вы беретесь рассуждать о "решении" задачи, о которой вы вообще ничего не знаете. Сколько там запросов, в какие таблицы, как именно обрабатываются данные перед вставкой.
Но я понимаю, вам хочется показать всем, что вы тоже уже знаете про insert с множественным value. И с этим желанием, увы, ничего не поделать.
Надо просто всегда учитывать, что вы на публичном ресурсе. И потом в этот вопрос придут люди из поиска. Которым банальный ответ про SQL будет только мешать
Ну вообще, вопрос довольно однозначный. Он про распараллеливание долгоиграющего процесса , а не про вставку.
Сама по себе вставка 3000 строк в одну таблицу проблемы не представляет: можно хоть все за 1 раз, хоть по одной - разница не принципиальная.
а что тут формулировать-то?
все операции совершенно стандартные
если вы не знаете, как запросить из вю информацию с бэкенда, то вам за парту, в первый класс, учить основы
если вы не знаете, как написать в ларавле контроллер, который по коду возвращает информацю о пользователе, то вам за парту, в первый класс, учить основы.
AUser0, то есть вы анлинкаете руками каждый загруженный файл, серьёзно?
Это граничит с гениальностью. Потому что кроме вас двоих такая прекрасная идея никому больше в голову не пришла.
Покажите мне код проекта, и я на спор найду в нем участок, который тратит ресурсов в тысячу раз больше, чем вот этот вызов. Но который при этом все равно ни на что не влияет.
Как я уже говорил люди делятся на два типа - тех кто понимает как делать оптимизации, и теоретиков, которые оптимизируют воображаемые проблемы. Со вторыми говорить бесполезно
Stalker_RED, обычно это стремление "сразу писать оптимизированный синтаксис" ни к чему хорошему не приводит. А только вот к таким вот идиотским проверкам на пустом месте. Заранее можно оптимизировать алгоритмы и обработку данных. А не ковычки и перекладывание из пустого в порожнее.
Если у вас функция вызывается миллион раз, то надо разбираться, как уменьшить это число. В крайнем случае - писать специальный для этого вариант вызова.
А не лепить бессмысленные проверки по всему коду в ожидании, что "вдруг будет вызываться миллион раз"
Но обычно читаемость и единство стиля в проекте важнее, чем размышления рядового кодера о производительности, и да - правильнее делать так, как скажет лид.
Еще раз.
Оптимизация кода - это не писать идиотские команды от балды.
Оптимизация кода - это сначала поиск узкого места, который программисты называют словом профайлинг, а потом оптимизация конкретно этого места, про которое конкретно известно, что оно виновато в избыточном потреблении памяти.
Например в приложении нужно получить только одну строку из базы данных, а оно, как у всех идиотов, считывает всю таблицу. программист в этом случае проводит замеры - в каком месте программы потребление памяти резко вырастает. Находит это идиотское место, и меняет запрос, чтобы он возвращал только одну строку. Вот это будет реальная оптимизация.
Но если вы общаетесь с идиотами, которые не слышали про профайлинг, но сами себя считают гениями программирования, то говорить им это бесполезно. Они будут продолжать долдонить про экономию двух байт.
Если человек оптимизирует проект не по результатам профайлинга, а "чтобы чуть-чуть", то он идиот.
Никогда не следует спорить с идиотами, потому что это всё равно бесполезно.
На вашем месте я бы просто согласился с ним, добавил эту бессмысленную проверку, и по возможности свалил как можно быстрее из этого места, от коллеги-идиота и размазни тимлида, на мнение которого коллеги кладут с прибором.
if (!isset($_SESSION['admin']))А то же будет ведь ругаться на несуществующий ключ
И я бы все-таки die писал отдельно от header.