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 про схему: клиент-приложение на машине пользователя обращающееся к удаленной СУБД напрямую без промежуточных звеньев.
shurshur, а что именно стало лучше и удобнее? Я так понимаю, для выборок вам нужны данные из всех таблиц, следовательно здесь стало хуже. Ускорилась вставка из-за меньшего объема данных, более коротких блокировках и блокировки идут на разные таблицы, так?
На сайте таблица не выглядит большой, о каких объемах идет речь?
mayton2019, "сжатие вертикальных колонок" - это вы похоже про колоночные СУБД, а это вообще к вопросу не относится. И индексы в классическом понимании там не используются, потому что принципы другие, т.к. задачи другие.
yarovikov, никак не сделаете оптимально, потому что данные в базе нужно располагать не так, чтобы они красиво лежали, а чтобы соответствовали тем селектам, которые вы будете направлять в базу. Если знаете, что и как будете запрашивать, то сможете спроектировать базу. Если не знаете, то это уже преждевременная оптимизация, которая ненужна.
Тем не менее, очень сомневаюсь, что вам понадобится выборка по 50-60 числовым полям. И тут, предложенный вариант с key-value или даже json выглядет более вероятными. Тем более с вашим объемом данных, будет не проблема поменять структуру БД при изменении требований.
И, кстати, строковые это какие? Какая у них максимальная длина?
webseodesigner, чтобы пользователю выводилось что-то осмысленное, делаете общий обработчик ошибок и формируете нужный ответ API, если хочется чтобы было что-то конкретное по ошибке, то перехватываете и в обработчик уже передаете нужное сообщение.