Ну вообще, вопрос довольно однозначный. Он про распараллеливание долгоиграющего процесса , а не про вставку.
Сама по себе вставка 3000 строк в одну таблицу проблемы не представляет: можно хоть все за 1 раз, хоть по одной - разница не принципиальная.
а что тут формулировать-то?
все операции совершенно стандартные
если вы не знаете, как запросить из вю информацию с бэкенда, то вам за парту, в первый класс, учить основы
если вы не знаете, как написать в ларавле контроллер, который по коду возвращает информацю о пользователе, то вам за парту, в первый класс, учить основы.
AUser0, то есть вы анлинкаете руками каждый загруженный файл, серьёзно?
Это граничит с гениальностью. Потому что кроме вас двоих такая прекрасная идея никому больше в голову не пришла.
Покажите мне код проекта, и я на спор найду в нем участок, который тратит ресурсов в тысячу раз больше, чем вот этот вызов. Но который при этом все равно ни на что не влияет.
Как я уже говорил люди делятся на два типа - тех кто понимает как делать оптимизации, и теоретиков, которые оптимизируют воображаемые проблемы. Со вторыми говорить бесполезно
Stalker_RED, обычно это стремление "сразу писать оптимизированный синтаксис" ни к чему хорошему не приводит. А только вот к таким вот идиотским проверкам на пустом месте. Заранее можно оптимизировать алгоритмы и обработку данных. А не ковычки и перекладывание из пустого в порожнее.
Если у вас функция вызывается миллион раз, то надо разбираться, как уменьшить это число. В крайнем случае - писать специальный для этого вариант вызова.
А не лепить бессмысленные проверки по всему коду в ожидании, что "вдруг будет вызываться миллион раз"
Но обычно читаемость и единство стиля в проекте важнее, чем размышления рядового кодера о производительности, и да - правильнее делать так, как скажет лид.
Еще раз.
Оптимизация кода - это не писать идиотские команды от балды.
Оптимизация кода - это сначала поиск узкого места, который программисты называют словом профайлинг, а потом оптимизация конкретно этого места, про которое конкретно известно, что оно виновато в избыточном потреблении памяти.
Например в приложении нужно получить только одну строку из базы данных, а оно, как у всех идиотов, считывает всю таблицу. программист в этом случае проводит замеры - в каком месте программы потребление памяти резко вырастает. Находит это идиотское место, и меняет запрос, чтобы он возвращал только одну строку. Вот это будет реальная оптимизация.
Но если вы общаетесь с идиотами, которые не слышали про профайлинг, но сами себя считают гениями программирования, то говорить им это бесполезно. Они будут продолжать долдонить про экономию двух байт.
Если человек оптимизирует проект не по результатам профайлинга, а "чтобы чуть-чуть", то он идиот.
Никогда не следует спорить с идиотами, потому что это всё равно бесполезно.
На вашем месте я бы просто согласился с ним, добавил эту бессмысленную проверку, и по возможности свалил как можно быстрее из этого места, от коллеги-идиота и размазни тимлида, на мнение которого коллеги кладут с прибором.
вот только mysqli_real_escape_string надо убрать, эта функция вообще никогда не нужна.
а htmlspecialchars надо применять только при выводе в HTML, а здесь её быть не должно.
И непонятно, почему вы используете fetch_assoc а не fetch_all. Ведь запрос с like может вернуть и больше одной строки
Lion97icvc, ну вообще, по ссылке, которую вам давали, именно это и написано:
ВАЖНО: нельзя добавлять к знакам вопроса кавычки — вы добавляете плейсхолдеры, а не строки.
Дальше, озаботившись невозможностью добавить знаки процента, можно набрать в браузере mysqli prepare like и сразу получить ответ на свой вопрос.
Я это не к тому чтобы вас упрекнуть: никто не воспринимает новую информацию целиком с первого раза. А скорее к тому, что вопрос не всегда только в наличии документации.
А в чем неточность-то?
Если бы было наоборот - то да, это была бы проблема.
А здесь-то какая разница? Выбираете из этих 5 таблиц одним запросом, и выгружаете в CSV
Я тут подумал что файл, скорее всего, остался как был. А бинарным его посчитала какая-то программа, которой наш гений его просматривает. Из-за какого-то одного непечатного символа.
Владимир, если вам нужен OLAP, то его опять же надо делать в специализированном хранилище, а не "в JS".
Здесь много бегает любителей демонстрировать всем окружающим размер своей учоности, но неспособных прочитать простой вопрос новичка и ответить на него.
Владимир, про "некоторые случаи" у меня и так написано, спасибо можно не повторяться.
Ваш же пример высосан из пальца. Ваш "куб" прекрасно раскладывается на индексы, которые уже лежат в оперативке и выборка по которым ничего никуда не положит. В отличие от выборки и перекачивания гигов сырых данных.
Сама по себе вставка 3000 строк в одну таблицу проблемы не представляет: можно хоть все за 1 раз, хоть по одной - разница не принципиальная.