как минимум, вы выбрали режим работы tcp, следовательно haproxy в принципе не контролирует url и прочие http-шные штуки. К тому же, не очень понятно зачем для изменения url использовать балансировщик.
Akina, т.е. я не прав, вы все таки описываете, что есть бек-приложение на сервере, которое общается с базой, и к которому обращается клиент с фронта? И при этом предлагаете перекинуть всю валидацию в базу с него? Тогда не понятны утверждения, о том, что проблема организовать доступ к БД только для приложения, почему мы не можем доверять серверному приложению, и откуда взялась непогрешимость валидации в БД.
Мы делаем проверку на клиенте и на сервере не потому что чем больше проверок тем лучше, а потому, что безопасно проверить может только сервер (но не обязательно СУБД), а проверка на клиенте (машина подконтрольная пользователю) позволяет обойтись без лишних запросов на сервер. Если бы не это, можно было бы обойтись и одной проверкой.
Никто не отвергает проверку ограничения типов на стороне БД, но полностью перенести в нее бизнес-логику по валидации проблематично:
- всю ее не перенести, достаточно несложных условий и их уже придется проверять через хранимые процедуры;
- перетягивание логики в базу, усложняет ее версионирование, и очень усложняет деплои и откаты;
- размазывание бизнес-логики по 2 кодовым базам очень неудобно;
- тестирование логики в базе в разы сложнее, чем в коде; и вместо простейшего юнит-теста выполняющегося мгновенно, нам понадобится тест, который будет лезть в базу, т.е. часть тестов замедлится порядка на 3;
- БД в 99% узкое место, не нужно ее еще дополнительно грузить;
- проверка в приложении на порядки быстрее, чем постоянная передача данных на другой сервер для проверки;
- не прошедшая валидация на сервере вызовет Exception на стороне сервера приложений, Exception всегда медленный, это исключительная ситуация, но пользователь своими ошибками может породить их сколь угодно много;
- если часть данных хранится в json, то валидации уже не будет;
- если мы обрабатываем массив от пользователя, и необходимо обработать валидное, а невалидное вернуть обратно, то необходима проверка до вставки в базу, иначе придется вставлять данные в базу построчно.
В принципе вариант возможный, если нам не важна производительность, но я плохо себе представляю, для какого проекта это может быть актуально. Тем более, если мы говорит про MySQL. И уже совсем все плохо с проверками на стороне БД, если мы работаем с высокими нагрузками.
DevMan, Akina, вы пишите о разных вещах. DevMan описывает схему типичную для веб: фронт-клиент на машине пользователя, бек-приложение на сервере, и оно общается с БД. Akina про схему: клиент-приложение на машине пользователя обращающееся к удаленной СУБД напрямую без промежуточных звеньев.
shurshur, а что именно стало лучше и удобнее? Я так понимаю, для выборок вам нужны данные из всех таблиц, следовательно здесь стало хуже. Ускорилась вставка из-за меньшего объема данных, более коротких блокировках и блокировки идут на разные таблицы, так?
На сайте таблица не выглядит большой, о каких объемах идет речь?
mayton2019, "сжатие вертикальных колонок" - это вы похоже про колоночные СУБД, а это вообще к вопросу не относится. И индексы в классическом понимании там не используются, потому что принципы другие, т.к. задачи другие.
yarovikov, никак не сделаете оптимально, потому что данные в базе нужно располагать не так, чтобы они красиво лежали, а чтобы соответствовали тем селектам, которые вы будете направлять в базу. Если знаете, что и как будете запрашивать, то сможете спроектировать базу. Если не знаете, то это уже преждевременная оптимизация, которая ненужна.
Тем не менее, очень сомневаюсь, что вам понадобится выборка по 50-60 числовым полям. И тут, предложенный вариант с key-value или даже json выглядет более вероятными. Тем более с вашим объемом данных, будет не проблема поменять структуру БД при изменении требований.
И, кстати, строковые это какие? Какая у них максимальная длина?
webseodesigner, чтобы пользователю выводилось что-то осмысленное, делаете общий обработчик ошибок и формируете нужный ответ API, если хочется чтобы было что-то конкретное по ошибке, то перехватываете и в обработчик уже передаете нужное сообщение.
Оба варианта имеют право на жизнь, какой выбрать зависит от многих факторов.
Выбирайте тот, который вы считаете более удобным.
В принципе, 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 из них.
Вероятно у меня просто иное понимание выражения "отличный специалист".