mayton2019, мы используем абстракции не ради самих абстракций. Использование абстракций - это попытки обобщенного программирования, для возможностей расширения кода основываясь на универсальных решениях, дабы не натыкаться на жесткую специализированность. И, согласен, далеко не всегда они нужны, фанатичное следование приведет к высокой раздробленности кода, это как Чистый Код Мартина - вроде бы очень универсально, но на практике не применимо.
Тем не менее, пользоваться консолью придется, т.к. это проще и универсальнее.
Cкорее всего драйвера non-free, поэтому посмотрите здесь https://wiki.debian.org/Firmware описание как они устанавливаются. Как минимум, на флешке они должны быть в директории firmware.
Сергей Горностаев, все языки можно разделить по задачам, где их применение оправдано, а где нет. Но, они от этого не перестают быть языками общего назначения. Каким бы общим не был Си, его применение ограничено, не потому что не может, а потому, что другие языки подходят лучше. Тупо, вы же не будете писать сайт на Си в большинстве случаев, перестал он от этого быть языком общего назначения - нет, не перестал. В отличии от каких-нибудь 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 про схему: клиент-приложение на машине пользователя обращающееся к удаленной СУБД напрямую без промежуточных звеньев.
webseodesigner, чтобы пользователю выводилось что-то осмысленное, делаете общий обработчик ошибок и формируете нужный ответ API, если хочется чтобы было что-то конкретное по ошибке, то перехватываете и в обработчик уже передаете нужное сообщение.
Оба варианта имеют право на жизнь, какой выбрать зависит от многих факторов.
Выбирайте тот, который вы считаете более удобным.
В принципе, 3 запроса увеличат расходы на сетевой лаг, особенно если он у вас большой, но не факт что объединенный в 1 запрос они будут выполняться суммарно быстрее (если этот вопрос важный, то нужно проверять оба варианта). Как тот, или иной вариант скажется на читабельности и расширяемости кода, знаете только вы. Насчет затащить в 1 запрос еще и дополнительную логику зависит от ваших принципов построения архитектуры, зачастую логику стараются держать вне базы, так проще управлять и гораздо легче масштабироваться, ведь база чаще всего самое узкое место. Но есть и адепты все затащить в базу.