Сергей Горностаев, все языки можно разделить по задачам, где их применение оправдано, а где нет. Но, они от этого не перестают быть языками общего назначения. Каким бы общим не был Си, его применение ограничено, не потому что не может, а потому, что другие языки подходят лучше. Тупо, вы же не будете писать сайт на Си в большинстве случаев, перестал он от этого быть языком общего назначения - нет, не перестал. В отличии от каких-нибудь DSL, заточенных под конкретную задачу, или процедурных языков в СУБД.
Василий Банников, Сергей Горностаев, цитата может и верная, только вырванная из контекста, да еще и перевранная в эту чушь: "Go - это изначально узкоспециализированный язык, созданный лишь для того, чтобы слабые разработчики могли быстро начать писать асинхронные сетевые сервисы, который по недоразумению выпал в более широкую сферу применения."
Создатели языка писали совсем иное: один из аспектов успешности языка - это простота, чтобы молодые разработчики быстрее начинали писать коммерческий код, а не занимались академическими поисками "совершенного" языка. Причем это только один из аспектов, не единственный! Поэтому утверждение выше чушь. А как мы видим по успешности Go - его разработчики оказались правы.
Я ни сколько не говорю что Rust хуже, да и у Go хватает проблем. Но Go такой же узкоспециализированный как Си, в принципе как и любой другой язык. А ставить языку в упрек простоту - глупость.
И пока "гениальные" разработчики обвиняют Go в том, что он не "божественен", обычные разработчики, не делая из языка культа, используя этот инструмент успешно решили и решают множество задач.
rPman, сравнить 2 короткие строки должно быть быстрее, чем вызвать функцию, да еще и внутри чтото поделать. С id для классов очень странное решение, польза которого сомнительна, запутаться в id проще. Но с посылом согласен, очень странно, что методу без разницы строка или объект, и скорее всего это нужно разделить на 2 метода, а может вообще выкинуть вызов ненужного типа.
как минимум, вы выбрали режим работы 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 строчки. Откуда большие методы?