Оба варианта имеют право на жизнь, какой выбрать зависит от многих факторов.
Выбирайте тот, который вы считаете более удобным.
В принципе, 3 запроса увеличат расходы на сетевой лаг, особенно если он у вас большой, но не факт что объединенный в 1 запрос они будут выполняться суммарно быстрее (если этот вопрос важный, то нужно проверять оба варианта). Как тот, или иной вариант скажется на читабельности и расширяемости кода, знаете только вы. Насчет затащить в 1 запрос еще и дополнительную логику зависит от ваших принципов построения архитектуры, зачастую логику стараются держать вне базы, так проще управлять и гораздо легче масштабироваться, ведь база чаще всего самое узкое место. Но есть и адепты все затащить в базу.
Спасибо, не знал, удалил свой ответ, чтобы не вводить в заблуждение.
Насчет char в PostgreSQL, поясните, пожалуйста, почему динамической длины? Разве он не зарезервирует сразу длину = n char X максимальную длину 1 char? А если он хранит строку как тип varchar, т.е. с отдельным хранением длины строки, зачем тогда хранить дополнительные пробелы, в выводе они понятное дело нужны, но зачем внутри их хранить?
Adamos, не PDO а prepared statements, они есть и в mysqli. И что в mysqli, что в PDO, если их не использовать, то скорее всего будет дыра.
havertz, локализуйте ошибку: откройте лог и прочитайте ошибки, все равно не понятно - запускайте дебаггер.
Проверьте, что данные отправляются на сервер. Проверьте, что скрипт php эти данные получил, из вашего примера не видно, чтобы что-то положило данные в массивы $names и т.д. Дальше, вы пытаетесь в sql запрос запихнуть массивы, а не конкретные значения. А после 1 итерации цикла выполняете редирект.
xotkot, можно попробовать, но там скорее всего начнутся проблемы с процом, все это паковать и распаковывать, на такой машине он очень слабый.
Lord_of_Rings, если раньше места хватало, то единственный вариант переустанавливать Винду, т.к. на 10ке место сжирают обновления, а удалить их проблематично. Лучше рассмотреть вариант с другой ОС.
Брать надо ту, которую знаешь, и в первую очередь со стороны администрирования. Что значит 'хай энд'? Понты - это не критерий в техническом выборе. Если же подразумевалось 'высокая нагрузка', то MySQL прекрасно подходит для высоких нагрузок.
Не нарушайте принцип единственной ответственности. Вы перечислили 4 задачи, выполняемые контроллером, даже если они все должны быть в контроллере - это 4 строчки. Откуда большие методы?
Это просто кусок ужасного кода, его нужно выбросить и забыть. Его понимание ничего не скажет о навыках чтения кода, разве что о навыках чтениия чего-то такого же ужасного.
Beeshop87, а ещё регистрация, открытие счета, за который надо платить, подача декларации.
Кроме того, это незаконно и является уклонением от уплаты налогов. И хотя ипшников обычно не трогают, теоретически могут доказать преступный сговор.
Для компании это выгодно, т.к. 6% это в разы меньше чем по договору. Т.к. при отсутствии льгот компания может платить чуть ли не 50% с дохода сотрудника, это ндфл, опс, омс и прочее. Не говоря уже о необходимости вести отчётность по сотрудникам.
Сергей Горностаев, не просто, как и разработка или администрирование сложных проектов. И я видел пентестеров, но вопрос в уровне знаний и навыков, который вы им приписываете. Неужели в Сбере у каждого из них за плечами более 10 лет в разработке (причем и фронт, и бек, и мобильная разработка, прикладное, системное), более 10 лет в администрировании (причем различных систем), 10 лет сетевым инженером, 10 лет психологом? И при этом они постоянно изучают новое и практикуют в этих областях? Если же нет, то какие они отличные специалисты?
Безусловно не просто, но невозможно быть именно отличным специалистом во всех областях знаний, которые вы перечислили, за 1 человеческую жизнь. В одной только разработке до фига специализаций, и если кто-то специалист в них во всех, то он вряд ли будет отличным специалистом хотя бы в 1 из них.
Вероятно у меня просто иное понимание выражения "отличный специалист".
Сергей Горностаев, да не боги они, а в большинстве команий нет вообще никаких пентестеров. Расскажите, где вы видели этих мифических созданий, который знают все и вся, да еще и работают пентестерами?
Разработчиков, админов с отличными знаниями найти огромная проблема, а вы толкуете про пентестеров, которые в одном лице и тот, и другой, и еще в других областях тоже отличный специалист.
Сергей Горностаев, пентестер - такой же человек, как и все остальные. И как любой человек он не может знать все и вся. Он просто проверяет известные уязвимости. Безусловно должно быть хорошая база, но ровна та, которая позволит ему эти уязвимости эксплуатировать, не более того. Нельзя быть специалистом во всем сразу, просто напросто жизни не хватит.
Поэтому:
Самое главное - чтобы сломать например Хабр, надо сначала уметь написать Хабр.
Совсем не обязательно для взлома уметь писать сложный код. К примеру, я знаю, что некоторый неанглийский символ unicode после привидения к нижнему регистру превращается в английский символ в одном или многих языках программирования. Мне достаточно создать свой почтовый ящик, похожий на email жертвы с заменой 1 этого символа, а затем сбросить его пароль на каком-нибудь популярном ресурсе. И если разработчики накосячили (а они это делают очень часто), то ссылка на смену пароля придет мне, а не хозяину.
И именно знания подобного рода в первую очередь важны для пентестера, а не, например, GRASP.
Сергей delphinpro, у вас в настройках указано правило только для static методов, поэтому если для динамических чтото и работает, то не эта настройка.
Т.е. уберете static, то будет "должны сначала идти методы public, потом protected и в конце private".
По алфавиту он тоже не будет сортировать, т.к. включено keep ordering.
Алексей Уколов, спасибо большое, очень интересно.
Да, внешние ключи первый кандидат на выброс при высокой нагрузке, я их вообще не использую, уж очень они замедляют работу.
Похоже из-за 1 индекса и небольшой длины строки вам удается вытягивать такое огромное кол-во. У меня примерно те же полтерабайта, но треть миллиарда строк (и где-то полтора десятка индексов), при увеличении кол-ва уже не так все быстро, как хотелось бы, хотя данные партиционированы горизонтально (2 таблицы 1 к 1). Но у меня и требования другие, вставки - это несколько миллисекунд, больше 10мс уже слишком долго. Да и данные не могу отложенно складывать. А с шардированием все очень сложно, не получается выбрать оптимальный параметр по которому шардироваться, т.к. запросы на выборки очень разные.
У меня на одном проекте есть таблица с ~6 000 000 000 строк, занимающая почти полтерабайта.
Чисто для интереса, можете, пожалуйста, указать какая СУБД. И, если можно, число индексов.
Сколько по времени занимает вставка 1 строки?
Обычно ближе к 1млрд. идет достаточно сильная деградация. Хотя 80 байт на строчку не так много, неаверное благодаря этому нет особых проблем.
Миша, для демонов нужно использовать systemd unit, а не cron.
24 в день? там на сервере вообще ничего не работает? а 30к не так уж и много.
Если же рассматривать вариант с cron, то делайте mutex, если сервер один, то можно файловый. Тогда стартующий по крону скрипт проверяет блокировку на какой-нибудь временный файл и если не может ее установить, то завершается. Но лучше, конечно, через systemd unit.
nikolay22323, да без разницы как назвать. А то, что "медленно работает" этот вопрос и надо задавать. Надо искать причину тормозов, а не выдумывать решение на пустом месте. Анализировать запросы. Проверять частоту чтения с диска, проверять что размер buffer pool соответствует объёму оперативки.
Выбирайте тот, который вы считаете более удобным.
В принципе, 3 запроса увеличат расходы на сетевой лаг, особенно если он у вас большой, но не факт что объединенный в 1 запрос они будут выполняться суммарно быстрее (если этот вопрос важный, то нужно проверять оба варианта). Как тот, или иной вариант скажется на читабельности и расширяемости кода, знаете только вы. Насчет затащить в 1 запрос еще и дополнительную логику зависит от ваших принципов построения архитектуры, зачастую логику стараются держать вне базы, так проще управлять и гораздо легче масштабироваться, ведь база чаще всего самое узкое место. Но есть и адепты все затащить в базу.