Какой необходимый уровень знаний sql для решения повседневных задач в бэкэнд разработке?
В общем начал изучать синтаксис замечательной СУБД - POSTGRESQL. Разобрался с основами языка(типы данных, связи таблиц, CRUD, DDL, подзапросы, вьюхи, джоины, функции sql и plsql и т.д) и назрел важный вопрос о том, на сколько глубоко стоит нырять в тему. С моей точки зрения большую часть логики можно описать в рамках основного языка программирования, после передав запрос к базе, не уверен в необходимости написания сложных функций и циклов на стороне базы. Я конечно понимаю, что знания лишними не бывают, но изучение всех фишек этой замечательной СУБД займет месяцы, которые можно потратить на освоение других технологий. Прошу людей, имеющих реальный боевой опыт решения бекенд задач, рассказать какими инструментами (речь именно об инструментах,предоставляемых СУБД) они пользуются, часто ли вы пишите функции, используете транзакции, циклы, или же вам хватает команд для получения данных из базы и их добавления.
функции и циклы редко, транзакции и внешние ключи - постоянно.
я бы на вашем месте скорее сосредоточился не на синтаксисе запросов а на архитектуре БД - нормальные формы, вот это вот всё
С моей точки зрения большую часть логики можно описать в рамках основного языка программирования, после передав запрос к базе, не уверен в необходимости написания сложных функций и циклов на стороне базы.
Напрасно. Стремление всё обработать на клиенте, а из сервера БД сделать тупое хранилище - одна из основных ошибок.
Почти любая обработка данных, которая может быть сделана на сервере БД, должна быть сделана именно там. Исключения достаточно нечасты.
Зависит от "повседневных" задач. Если не столкнетесь с адептами логики в базе, то написание хранимых процедур не понадобится. Обработка на стороне приложения как правило дешевле, но фильтрация данных и агрегация чаще всего осуществляется на стороне СУБД. Кроме основных операторов SQL нужно понимание транзакций (в том числе их уровней), варианты хранения данных (таблицы связей, EAV и прочее), нормализация, связи (внешние ключи используются почти всегда), индексы (не только какие бывают, но и как организовано сбалансированное дерево b-tree, как влияет селективность на выборку), план запроса, оптимизатор и сбор статистики, какие бывают локи и из-за чего, и для каких изменений нужно снимать нагрузку. Ну и сопутствующие вещи - миграции, фикстуры, драйверы СУБД, подготовленные запросы, sql-инъекции и т.п. Для начала достаточно иметь общее теоретическое понимание этих вещей, реально будете их изучать на практике, в зависимости от проектов и их нагрузки с разной степенью глубины.
Akina, поэтому и написал, что фильтрацию и агрегацию чаще всего делают на стороне СУБД. Тащить в приложение тысячи строк, чтобы выбрать 2 - глупость, но заставлять СУБД отрабатывать бизнес-логику гораздо дороже, нежели бы это сделало приложение.
Наверное, всё-таки сильно зависит от того, какова именно бизнес-логика. Если задача, скажем, итерационная, переборная и т.п., то да, скорее всего, лучше её делать на клиенте. Но всё же большинство бизнес-задач тупы, как валенок - выбрать по критериям, отсортировать, посчитать агрегаты, итоги... и это всё СУБД делает куда как лучше клиентского кода.
Akina, именно так, я имел ввиду несколько иное. Действия сокращающие выборку, с ними, конечно, лучше справляется СУБД. Т.е. суммы, среднее и прочие агрегационные функции, аналитические функции, все это в разы производительней сделать в СУБД. Но, когда запрос на получение данных превращается в обращение к процедуре, которая сама проверяет бизнес-условия, в которой вызываются другие процедуры, например авторизации и т.п. - это перебор. Это сильно перегружает базу со всеми вытекающими.
В силу широко распространенного "ща я тут все 100500 миллионов записей вытащу и на месте в цикле все посчитаю" - не, sql не очень нужен)
Но большей частью это от засилья бэкеров не освоивших sql,.. ну и не щупавших что такое добывать данные через тонкий канал.
Простой
