Почему sql популярен
Перейти к содержимому

Почему sql популярен

  • автор:

Что такое SQL?

Язык структурированных запросов (SQL) – это язык программирования для хранения и обработки информации в реляционной базе данных. Реляционная база данных хранит информацию в табличной форме со строками и столбцами, представляющими различные атрибуты данных и различные связи между значениями данных. Инструкции SQL можно использовать для хранения, обновления, удаления, поиска и извлечения информации из базы данных. Можно также использовать SQL для поддержания и оптимизации производительности базы данных.

Почему SQL так важен?

Язык структурированных запросов (SQL) – популярный язык запросов, который часто используется во всех типах приложений. Аналитики данных и разработчики изучают и используют SQL, потому что это решение хорошо интегрируется с различными языками программирования. Например, они могут внедрять SQL-запросы с языком программирования Java для создания высокопроизводительных приложений обработки данных с основными системами баз данных SQL, такими как Oracle или MS SQL Server. Решение SQL также довольно просто в освоении, так как в его утверждениях используются общепринятые английские ключевые слова.

История SQL

Решение SQL было изобретено в 1970-х годах на основе реляционной модели данных. Изначально оно было известен как структурированный английский язык запросов (SEQUEL). Позднее этот термин был сокращен до SQL. Компания Oracle, ранее – Relational Software, стала первым поставщиком, предложившим коммерческую систему управления реляционными базами данных SQL.

Каковы компоненты системы SQL?

Системы управления реляционными базами данных используют язык структурированных запросов (SQL) для хранения данных и управления ими. В системе хранится несколько таблиц базы данных, связанных друг с другом. MS SQL Server, MySQL или MS Access являются примерами систем управления реляционными базами данных. Ниже перечислены компоненты такой системы.

Таблица SQL

Таблица SQL – это базовый элемент реляционной базы данных. Таблица базы данных SQL состоит из строк и столбцов. Инженеры баз данных создают связи между несколькими таблицами базы данных, чтобы оптимизировать пространство для хранения данных.

Например, инженер баз данных создает таблицу SQL для продуктов в магазине:

Идентификатор продукта

Название продукта

Идентификатор цвета

Затем инженер базы данных связывает таблицу продуктов с таблицей цветов с идентификатором цвета:

Идентификатор цвета

Название цвета

Операторы SQL

Инструкции SQL, или SQL-запросы, являются действительными инструкциями, понятными системам управления реляционными базами данных. Разработчики программного обеспечения создают инструкции SQL, используя различные языковые элементы SQL. Элементы языка SQL – это такие компоненты, как идентификаторы, переменные и условия поиска, которые формируют правильную инструкцию SQL.

Например, следующая инструкция SQL использует команду SQL INSERT для хранения матраса марки A стоимостью 499 долларов США в таблице с именем Mattress_table с именами столбцов brand_name и cost:

ВСТАВКА В MATTRESS_TABLE (brand_name, cost)

Хранимые процедуры

Хранимые процедуры – это набор из одной или нескольких инструкций SQL, хранящихся в реляционной базе данных. Разработчики программного обеспечения используют хранимые процедуры для повышения эффективности и производительности. Например, они могут создать хранимую процедуру обновления таблиц продаж вместо написания одной и той же инструкции SQL в разных приложениях.

Как работает SQL?

Реализация языка структурированных запросов (SQL) включает серверную машину, которая обрабатывает запросы к базе данных и возвращает результаты. Процесс SQL проходит через несколько программных компонентов, включая указанные ниже.

Парсер

Синтаксический анализатор начинает с токенизации или замены некоторых слов в инструкции SQL специальными символами. Затем он проверяет инструкцию на наличие указанного ниже.

Корректность

Анализатор проверяет соответствие инструкции SQL семантике или правилам SQL, которые обеспечивают правильность инструкции запроса. Например, синтаксический анализатор проверяет, заканчивается ли команда SQL точкой с запятой. Если точка с запятой отсутствует, синтаксический анализатор возвращает ошибку.

Авторизация

Парсер также проверяет, что пользователь, выполняющий запрос, имеет необходимые полномочия для манипулирования соответствующими данными. Например, только пользователи с правами администратора могут иметь право удалять данные.

Реляционный движок

Реляционный движок, или обработчик запросов, создает план наиболее эффективного извлечения, записи или обновления соответствующих данных. Например, он проверяет наличие похожих запросов, повторно использует предыдущие методы обработки данных или создает новый. Он записывает план в промежуточном представлении инструкции SQL, называемой байтовым кодом. Реляционные базы данных используют байтовый код для эффективного поиска и модификации баз данных.

Движок хранения

Ядро хранения или ядро базы данных – это программный компонент, который обрабатывает байтовый код и выполняет предполагаемую инструкцию SQL. Система считывает и сохраняет данные в файлах базы данных на физическом диске. По завершении механизм хранения возвращает результат запрашивающему приложению.

Что такое команды SQL?

Команды языка структурированных запросов (SQL) – это специальные ключевые слова или инструкции SQL, которые разработчики используют для управления данными, хранящимися в реляционной базе данных. Команды SQL можно классифицировать указанным ниже образом.

Язык определения данных

Язык определения данных (DDL) относится к командам SQL, которые проектируют структуру базы данных. Инженеры баз данных используют DDL для создания и изменения объектов базы данных в соответствии с бизнес-требованиями. Например, инженер баз данных использует команду CREATE для создания объектов базы данных, таких как таблицы, представления и индексы.

Язык запроса данных

Язык запросов данных (DQL) состоит из инструкций по извлечению данных, хранящихся в реляционных базах данных. Программные приложения используют команду SELECT для фильтрации и возврата определенных результатов из таблицы SQL.

Язык управления данными

В инструкциях языка управления данными (DML) записывается новая информация или изменяются существующие записи в реляционной базе данных. Например, приложение использует команду INSERT для сохранения новой записи в базе данных.

Язык управления данными

Администраторы баз данных используют язык управления данными (DCL) для управления или авторизации доступа к базе данных для других пользователей. Например, они могут использовать команду GRANT, чтобы разрешить определенным приложениям манипулировать одной или несколькими таблицами.

Язык управления транзакциями

Реляционный механизм использует язык управления транзакциями (TCL) для автоматического внесения изменений в базу данных. Например, база данных использует команду ROLLBACK для отмены ошибочной транзакции.

Что такое стандарты SQL?

Стандарты SQL – это набор формально определенных рекомендаций языка структурированных запросов (SQL). Американский национальный институт стандартов (ANSI) и Международная организация по стандартизации (ISO) приняли стандарты SQL в 1986 году. Поставщики программного обеспечения используют стандарты ANSI SQL для создания программного обеспечения баз данных SQL для разработчиков.

Что такое внедрение SQL-кода?

SQL-инъекция – это кибератака, которая включает в себя обман базы данных с помощью SQL-запросов. Хакеры используют внедрение SQL-кода для извлечения, изменения или повреждения данных в базе данных SQL. Например, они могут заполнить SQL-запрос вместо имени человека в форме отправки, чтобы выполнить внедрение SQL-кода.

Что такое MySQL?

MySQL – это система управления реляционными базами данных с открытым исходным кодом, предлагаемая Oracle. Разработчики могут загружать и использовать MySQL без оплаты лицензионного сбора. Они могут устанавливать MySQL в разных операционных системах или облачных серверах. MySQL – популярная система баз данных для веб-приложений.

Сравнение SQL и MySQL

Язык структурированных запросов (SQL) – это стандартный язык для создания баз данных и управления ими. MySQL – это программа реляционных баз данных, использующая SQL-запросы. Хотя команды SQL определяются международными стандартами, программное обеспечение MySQL постоянно обновляется и совершенствуется.

Что такое NoSQL?

NoSQL относится к нереляционным базам данных, которые не используют таблицы для хранения данных. Разработчики хранят информацию в различных типах баз данных NoSQL, включая графики, документы и ключевые значения. Базы данных NoSQL популярны в современных приложениях, поскольку они масштабируются по горизонтали. Горизонтальное масштабирование означает увеличение вычислительной мощности за счет добавления большего количества компьютеров с программным обеспечением NoSQL.

Сравнение SQL и NoSQL

Язык структурированных запросов (SQL) обеспечивает единый язык обработки данных, но реализация NoSQL зависит от разных технологий. Разработчики используют SQL для транзакционных и аналитических приложений, тогда как NoSQL подходит для гибких и интенсивных приложений.

Что такое SQL-сервер?

SQL Server – это официальное название системы управления реляционными базами данных Microsoft, которая обрабатывает данные с помощью SQL. MS SQL Server имеет несколько выпусков, каждая из которых предназначена для конкретных рабочих нагрузок и требований.

Как AWS поддерживает SQL?

Microsoft SQL Server на AWS позволяет разработчикам запускать рабочие нагрузки Microsoft SQL на AWS. Система баз данных SQL лучше работает с масштабируемыми вычислительными ресурсами AWS. Используя MS SQL на AWS, компании достигают более высокой доступности сервисов, поскольку AWS имеет самую широкую глобальную инфраструктуру в 24 регионах. SQL Server на AWS интегрируется с более чем 230 сервисами безопасности, соответствия требованиям и управления для защиты данных от внешних угроз. Некоторые другие способы поддержки SQL AWS включают указанное ниже.

  • Клиенты используют сервис Сервис миграции баз данных Amazon, чтобы упростить перенос баз данных SQL в AWS.
  • Магазин эластичных блоков Amazon (EBS) предоставляет высокопроизводительное блочное хранилище для критически важных SQL-приложений.

Начните работу с SQL Server на AWS, зарегистрировав аккаунт AWS уже сегодня.

Почему SQL одерживает верх над NoSQL, и к чему это приведет в будущем

SQL пробуждается и наносит ответный удар силам тьмы — NoSQL

С самого начала компьютерной эры человечество собирает экспоненциально растущие объемы данных, и вместе с этим растут требования к системам хранения, обработки и анализа данных. Из-за этого в последнее десятилетие разработчики ПО отказались от SQL как от устаревшей технологии, которая не могла масштабироваться вместе с растущими объемами данных — и в результате появились базы данных NoSQL: MapReduce и Bigtable, Cassandra, MongoDB и другие.

Однако сейчас SQL возрождается. Все основные поставщики облачных услуг предлагают популярные управляемые сервисы реляционных баз данных: Amazon RDS, Google Cloud SQL, база данных Azure для PostgreSQL (запущена буквально в этом году) и другие. Если верить компании Amazon, ее совместимая с PostgreSQL и MySQL база данных Aurora стала «самым быстрорастущим сервисом в истории AWS». Не теряют популярности и SQL-интерфейсы поверх платформ Hadoop и Spark. А в прошлом месяце поддержку SQL запустила и Kafka. Авторы статьи скромно признаются, что и сами разрабатывают новую базу данных временных рядов, которая полностью поддерживает SQL.

В этой статье мы попробуем разобраться, почему маятник качнулся назад в сторону SQL и чего ждать специалистам по разработке и анализу баз данных.

Переведено в Alconost

Часть 1. Новая надежда

Чтобы понять, почему SQL возвращается, давайте вернемся в самое начало и разберемся, почему эта технология вообще появилась.

Как и все хорошие истории, наша начинается в 70-е

Эта реляционная база данных родилась в подразделении IBM Research в начале 70-х гг. В то время языки запросов основывались на сложной математической логике и не менее сложной нотации. Два свежеиспеченных кандидата наук, Дональд Чемберлин и Раймонд Бойс, впечатлились реляционной моделью данных, но при этом увидели, что используемый язык запросов будет препятствовать ее распространению. Они решили разработать новый язык запросов, который, по их словам, будет «более удобным для пользователей, не прошедших курс математики или компьютерного программирования».

Языки запросов до SQL (пп. А, Б) в сравнении с SQL (источник)

Просто представьте себе: еще не было ни Интернета, ни персональных компьютеров, «Cи» только-только вышел в свет, а два молодых специалиста в области вычислительных систем уже поняли, что «успех компьютерной отрасли в большей степени зависит от развития категории пользователей, а не категории обученных компьютерных специалистов». Им нужен был язык запросов, который читается так же легко, как английский, но при этом дает возможность администрировать базы данных и работать с ними.

В результате появился SQL, впервые представленный миру в 1974 году, и в следующие несколько десятилетий он станет очень популярным. Поскольку в отрасли ПО обосновались реляционные базы данных (например, System R, Ingres, DB2, Oracle, SQL Server, PostgreSQL, MySQL и многие другие), SQL широко распространился как язык взаимодействия с БД и стал общепринятым в экосистеме, которая становилась все более конкурентной.

(К сожалению, Раймонду Бойсу не удалось увидеть успех SQL: он умер от аневризмы мозга через месяц после одного из первых докладов по SQL — в возрасте всего 26 лет; у него остались жена и маленькая дочь.)

Некоторое время казалось, что SQL выполнил свою задачу и все идет хорошо… Но тут появился Интернет.

Часть 2. NoSQL наносит ответный удар

Разрабатывая SQL, Чемберлин и Бойс не знали, что в Калифорнии работают над другим перспективным проектом, который впоследствии широко распространится и станет угрожать существованию SQL. Этот проект — ARPANET, дата его рождения — 29 октября 1969 г.

Создатели сети ARPANET (не все), которая в итоге превратилась в современный Интернет (источник)

Некоторое время SQL вел спокойное существование — пока в 1989 году еще один инженер не изобрел Всемирную паутину.

Физик, изобретший Интернет (источник)

Веб и Интернет росли и распространялись, как сорняк, бесчисленными способами меняя привычный мир, но у специалистов по базам данных появилась вполне конкретная головная боль: новые источники, генерирующие данные в гораздо больших объемах и намного быстрее, чем раньше.

С ростом сети Интернет разработчики ПО обнаружили, что реляционные базы данных не могут справиться с такой нагрузкой. Произошло возмущение в Силе, как будто миллионы баз данных вскрикнули от ужаса и так же внезапно умолкли, перегруженные.

Затем два новых интернет-гиганта совершили прорыв — разработали собственные распределенные нереляционные системы, предназначенные для решения проблемы с возрастающими объемами данных: MapReduce (публикация 2004 г.) и Bigtable (публикация 2006 г.) от компании Google и Dynamo (публикация 2007 г.) от компании Amazon. Упав на благодатную почву, опубликованные статьи дали хороший урожай нереляционных баз данных: Hadoop (на основе статьи по MapReduce, 2006 г.), Cassandra (авторы вдохновлялись статьями по Bigtable и Dynamo, 2008 г.), MongoDB (2009 г.) и др. Новые системы были написаны преимущественно с чистого листа, поэтому они тоже не использовали SQL, что привело к росту «движения NoSQL».

Творение компаний Google и Amazon распространилось, похоже, гораздо шире, чем предполагали сами авторы. И понятно, почему так случилось: NoSQL-системы были в новинку; они обещали масштабирование и мощь; казалось, что это — быстрый путь к успешной разработке. И тут начали вылезать проблемы.

Разработчик, поддавшийся искушению NoSQL. Не делайте так.

Вскоре разработчики обнаружили, что отсутствие SQL на самом деле существенно ограничивает. У каждой базы данных NoSQL был собственный уникальный язык запросов, а это означало следующее: нужно было изучать больше языков (и обучать своих коллег); подключать эти базы данных к приложениям было сложнее, что заставляло писать тонны неустойчивого связующего кода; отсутствие сторонней экосистемы — а значит, компаниям приходилось разрабатывать собственные инструменты для визуализации и работы с БД.

Языки NoSQL только появились, поэтому их нельзя было назвать полными и завершенными: в реляционных БД, к примеру, многие годы работали над добавлением в SQL необходимых функций (JOIN, например). Такая незрелость означала бо́льшую сложность на уровне приложения. Отсутствие операторов JOIN также приводило к денормализации, итогом чего было «раздувание» данных и недостаток гибкости.

Некоторые базы данных из лагеря NoSQL добавили собственные SQL-подобные языки запросов — например, CQL в БД Cassandra. И часто становилось только хуже: использование интерфейса, который почти совпадает с чем-то более распространенным, по факту требовало больше умственных усилий, ведь в этом случае заранее неизвестно, какие из знакомых функций поддерживаются, а какие — нет.

SQL-подобные языки запросов — это как «Праздничный спецвыпуск» для «Звездных войн». Избегайте подражания. (И ни в коем случае не смотрите «Праздничный спецвыпуск».)

Кое-кто из специалистов уже на раннем этапе видел проблемы в NoSQL (например, ДеВитт и Стоунбрейкер — в 2008 г.). С течением времени к ним присоединялось все больше разработчиков ПО, которые прочувствовали эти проблемы на собственном горьком опыте.

Часть 3. Возвращение SQL

Соблазнившись поначалу «темной стороной», разработчики ПО вскоре узрели свет и понемногу начали возвращаться к SQL.

Сначала поверх платформ Hadoop и (чуть позже) Spark появились SQL-интерфейсы, благодаря чему в отрасли под «NoSQL» начали понимать «не только SQL» (хорошая попытка, ага).

Затем появились NewSQL — «новые SQL», масштабируемые базы данных с полной поддержкой SQL. Одной из первых масштабируемых БД с оперативной обработкой транзакций (OLTP) стала H-Store (публикация 2008 г.) Массачусетского технологического института и Брауновского университета. И снова не обошлось без разработок Google: своей первой статьей про Spanner (публикация 2012 г., среди авторов есть и создатели MapReduce) компания возглавила движение в сторону георепликационных БД с SQL-интерфейсом, и за ней последовали другие пионеры — например, CockroachDB (2014 г.).

В это же время начало возрождаться сообщество PostgreSQL: появились важные улучшения, например, тип данных JSON (2012 г.), а также винегрет из новых функций — в версии PostgreSQL 10: улучшенная встроенная поддержка секционирования и репликации, поддержка полнотекстового поиска для JSON и многое другое (вышла в октябре этого года). Другие разработчики, например, CitusDB (2016 г.) и авторы этих строк (TimescaleDB, выпущена в этом году) нашли новые способы масштабирования PostgreSQL для специализированных рабочих нагрузок.

Дорога, по который мы шли, разрабатывая TimescaleDB, очень похожа на путь отрасли в целом. В ранних внутренних версиях TimescaleDB имела собственный SQL-подобный язык запросов «ioQL» — да, темная сторона соблазнила и нас: казалось, что собственный язык запросов — это огромное преимущество. Поначалу это не казалось сложным, но вскоре мы поняли, что работы на самом деле предстоит намного больше, чем мы ожидали: например, нужно было определиться с синтаксисом, разработать «соединители», обучить этому языку пользователей и т. д. А еще обнаружилось, что мы — в собственноручно разработанном языке! — постоянно ищем правильный синтаксис для запросов, которые можем спокойно выразить через SQL.

Таким образом, однажды мы поняли, что разрабатывать собственный язык запросов — бессмысленно. Это привело нас к переходу на SQL и оказалось одним из лучших сделанных нами технологических решений: нам открылся совершенно новый мир. Сегодня нашей БД нет еще и 5 месяцев, а пользователи уже могут применять ее в работе и сразу «из коробки» иметь множество замечательных возможностей: инструменты визуализации (Tableau), соединители для популярных ORM, множество инструментов и вариантов резервного копирования, руководства и подсказки по синтаксису и т. д.

Не обязательно верить на слово нам — давайте посмотрим, что делает Google.

Более десятка лет компания Google находится, без сомнений, на переднем крае разработок в области разработки баз данных и соответствующей инфраструктуры. Поэтому следует уделять пристальное внимание тому, что они делают.

Взглянув на вторую крупную публикацию Google по БД Spanner, которая вышла совсем недавно (Spanner: Becoming a SQL System — «Spanner становится SQL-системой», май 2017 г.), вы обнаружите, что она подтверждает выводы, к которым мы пришли самостоятельно.

К примеру, инженеры Google начал надстраивать свою систему над Bigtable, но обнаружили, что отсутствие SQL создает сложности:

«Эти системы давали некоторое преимущество как базы данных, однако им не хватало многих традиционных функций БД, на которые часто полагаются разработчики приложений. Ключевой пример — отсутствие продуманного языка запросов, из-за чего разработчикам приложений для обработки и агрегирования данных приходилось писать сложный код. В итоге мы решили превратить Spanner в полнофункциональную SQL-систему, в которой выполнение запросов тесно связано с другими архитектурными особенностями БД (например, строгая согласованность и глобальная репликация)».

Далее в статье они подробнее обосновывают переход от NoSQL к SQL:

«У исходного API-интерфейса базы данных Spanner были методы NoSQL для точечного поиска и поиска по диапазонам отдельных и перемежающихся (англ. «interleaved») таблиц. Методы NoSQL упрощали запуск системы и по-прежнему удобны в простых задачах поиска, однако у SQL есть значительные преимущества при записи более сложных шаблонов доступа к данным и вычислениях на данных».

В статье также рассказывается, что переход на SQL не остановился на проекте Spanner, а по сути распространился на остальные технологии компании, где сегодня общий диалект SQL используется в нескольких системах:

«SQL-ядро БД Spanner использует «стандартный SQL» совместно с несколькими другими системами Google, в число которых входят и внутренние (среди них — F1 и Dremel), и внешние системы (например, BigQuery)…
Для пользователей внутри компании такой подход снижает барьер при работе с несколькими системами. Разработчик или специалист по анализу данных, который пишет SQL-запросы в Spanner, может использовать свои навыки в системе Dremel, не беспокоясь о тонкостях синтаксиса, обработке NULL и т. д.».

Успех такого подхода говорит сам за себя. Сегодня Spanner является платформой для основных систем Google, в числе которых AdWords и Google Play, и при этом «потенциальные клиенты облачных платформ в подавляющем большинстве заинтересованы в использовании SQL».
Весьма примечательно, что компания Google, которая помогла родиться движению NoSQL, сегодня возвращается в лоно SQL. (Поэтому кое-кто задался вопросом: «Разработчики Google сбили отрасль «больших данных» с истинного пути на 10 лет?»)

Будущее отрасли обработки данных: SQL как узкое место

В компьютерных сетях существует такое понятие, как «узкое место».

Эта идея возникла для решения главной задачи, которую можно сформулировать следующим образом. Возьмем какое-либо сетевое устройство и представим себе своеобразный «пирог» из слоев оборудования снизу и слоев программного обеспечения сверху. Сетевые устройства могут быть самыми разными; так же бывает и множество различных приложений и ПО. Задача состоит в том, чтобы ПО имело возможность подключаться к сети, какое бы оборудование не использовалось; а сетевое оборудование должно знать, как обрабатывать запросы сети, независимо от ПО.

«Узкое место» сетевых технологий (источник)

В сетях узкое место — протокол IP: он выступает в качестве общего интерфейса между сетевыми протоколами низкого уровня, предназначенными для локальной сети, и прикладными и транспортными протоколами высокого уровня. (Вот одно неплохое разъяснение.) И, если упрощать, этот интерфейс стал общепринятым для компьютерных систем: он позволяет объединять сети и обмениваться данными между устройствами. И эта «сеть сетей» превратилась в многогранный, полный различной информации Интернет, каким мы его знаем сегодня.

Авторы этой статьи полагают, что SQL стал узким местом в анализе данных.

Мы живем в эпоху, когда данные становятся «самым ценным ресурсом в мире» (The Economist, май 2017 г.). В результате мы имели удовольствие наблюдать «кембрийский взрыв» специализированных БД (OLAP, базы данных временных рядов, БД для документов, графов и т. д.), инструментов обработки данных (Hadoop, Spark, Flink), шин передачи данных (Kafka, RabbitMQ) и т. д. Появилось и большое число приложений, которые работают на такой инфраструктуре данных, будь то сторонние инструменты визуализации (Tableau, Grafana, PowerBI, Superset), веб-фреймворки (Rails, Django) или специально разработанные приложения, использующие БД.

Как и в случае компьютерных сетей, у нас есть сложный «пирог» с инфраструктурой в самом низу и приложениями вверху. Как правило, чтобы этот пирог работал, нам приходится писать много связующего кода. Но такой код ненадежен: его нужно старательно поддерживать.

Необходим общий интерфейс, который позволит частям этого пирога друг с другом взаимодействовать. Лучше всего — что-то, что уже является стандартом в отрасли. Что-то, что позволит менять местами различные слои с минимальными усилиями.

И здесь как раз самое место для SQL: как и IP, SQL — это общий интерфейс.

Но SQL все же универсальнее протокола IP: данные приходится анализировать и людям, а запросы на языке SQL, как и было задумано, могут быть прочитаны человеком.

Безупречен ли SQL? Нет. Но именно этот язык знаком большинству специалистов по базам данных. Конечно, где-то уже ведутся работы над интерфейсом, в большей степени ориентированным на естественный язык, но к чему будут подключаться такие системы? К SQL.

Таким образом, на самой вершине пирога есть еще один слой, и этот слой — мы.

SQL возвращается

SQL возвращается — и главная причина этого не в том, что писать связующий код для подключения NoSQL-инструментов надоедает. И не в том, что обучать специалистов множеству новых языков — это сложно. И не в том, что стандарты должны быть продуманными.

Главная причина в том, что наш мир полон данных: они окружают нас, связывают нас. Когда-то мы для их обработки полагались на собственные органы чувств и нервную систему. Теперь же и наши аппаратные системы и ПО становятся достаточно умными, чтобы помогать нам. Мы хотим лучше понимать окружающий мир, и для этого собираем все больше и больше данных — поэтому сложность систем хранения, обработки, анализа и визуализации этих данных будет только расти.

Мастер обработки данных Йода

У нас есть выбор: жить в мире хрупких систем и миллионов интерфейсов — или вернуться к SQL и восстановить нарушенное равновесие Силы.

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 68 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Что такое SQL: как устроен, зачем нужен и как с ним работать

Рассказываем о языке, на котором «говорят» большинство баз данных.

Иллюстрация: Оля Ежак для Skillbox Media

Иван Стуков

Иван Стуков
Журналист, изучает Python. Любит разбираться в мелочах, общаться с людьми и понимать их.

Вся информация, с которой вы сталкиваетесь в интернете, содержится в базах данных. В них же хранятся данные о сотрудниках и клиентах крупных компаний, научных и социологических исследованиях, расписании рейсов ближайшего к вам аэропорта и много о чём ещё.

Работать с этими циклопическими массивами информации вручную было бы долго, муторно и непродуктивно. Поэтому придумали SQL — специальный язык для общения с БД.

Что такое SQL

SQL (Structured Query Language, или язык структурированных запросов) — это декларативный язык программирования (язык запросов), который используют для создания, обработки и хранения данных в реляционных БД.

На чистом SQL нельзя написать программу — он предназначен только для взаимодействия с базами данных: получения, добавления, изменения и удаления информации в них, управления доступом и так далее.

Поэтому перед изучением SQL нужно разобраться, как устроены базы данных.

В каких базах данных используют SQL

Все БД можно поделить на два вида: реляционные и нереляционные. Язык SQL нужен для работы с первыми.

SQL настолько тесно связан с реляционными БД, что все нереляционные БД в противовес стали называть NoSQL. Вот и получилось, что SQL — это язык программирования, а NoSQL — тип баз данных.

Про реляционные БД часто говорят, что это набор двумерных таблиц. Прямо как в Excel: со столбцами, строками и ячейками. Это понятная визуализация, хотя и не совсем точная.

Представим, что мы создаём базу данных для небольшой строительной фирмы. Она проектирует загородные дома и передаёт проекты подрядчикам, которые занимаются самим строительством:

Чем же база данных отличается от таблицы? Тем, что в базе:

  • У столбцов и строк нет определённого положения. Нельзя сказать, что столбец status находится до или после столбца num_floors, а имя Анастасии Романиной — до или после имени Дмитрия Пожарова.
  • Каждый столбец диктует свой домен, то есть тип данных, к которому могут относиться его значения. Например, в столбцах cost и num_floors могут храниться только числа, а в столбце client — только строки.
  • Каждая строка должна быть уникальной и не может повторять какую-то другую строку.

Из-за этих отличий применительно к базам данных используют другую терминологию. Столбец называется атрибутом, строка — записью или кортежем, а сама БД — их отношением друг к другу.

Нормализация в реляционных базах данных

Вернёмся к БД нашей строительной фирмы. Она может казаться удобной, но на самом деле не лишена недостатков.

Возьмём дом, который строится для Марии Медичиной. Сейчас он только проектируется, и мы ещё не выбрали для него подрядчика. Поэтому значение атрибута contractor равно NULL, то есть поле пустое. Но рано или поздно мы выберем подрядчика — например, ООО «Коттеджи». Тогда, кроме имени подрядчика, нам нужно будет заново указать его телефон. Сейчас значение этого атрибута тоже NULL. Пока что сделать это несложно.

В реальной же базе данных о подрядчике будет храниться гораздо больше информации: адрес, почта, ИНН, банковские реквизиты и так далее. Чтобы каждый раз переписывать всю эту информацию, придётся делать много лишних движений — а это не наш метод.

Если подрядчик вдруг сменит номер телефона, во всех старых записях останется устаревшая информация. А таких записей могут быть сотни и тысячи (если наша компания станет совсем успешной). Ровно та же ситуация с данными клиентов. Уследить за таким числом нюансов проблемно, и наша БД рискует превратиться в хранилище фейков.

Чтобы этого не происходило, в реляционных БД используют нормализацию. Это когда одну таблицу разбивают (декомпозируют) на несколько, а каждой записи присваивают уникальный ключ, по которому её можно идентифицировать.

Всего существует шесть нормальных форм. Чем выше номер формы, тем большему количеству правил она должна подчиняться. Приведём базу данных нашей строительной фирмы в соответствие с третьей нормальной формой.

Теперь, если у любого клиента или подрядчика сменится телефон, нужно будет внести изменения всего один раз. Добавлять новые записи теперь тоже будет проще.

Таблицы связывают между собой ключами. Они бывают трёх видов.

Первичный — указывает на запись, к которой он относится. В одном отношении не может быть нескольких записей с одним и тем же первичным ключом, и значение первичного ключа не может быть NULL. Первичным ключом может быть любое уникальное значение. Например, в таблице contractors так можно было бы использовать ИНН, если б он был в нашей базе.

Внешний — содержит ссылку на первичный ключ из другой таблицы и привязывает одну таблицу к другой.

Родительский — это первичный ключ, на который ссылается внешний ключ.

Язык программирования SQL: как управлять базами данных

Ещё одно отличие реляционных БД от обычных таблиц — в них нельзя вносить изменения напрямую. Для этого нужны СУБД, или системы управления базами данных.

СУБД — это посредник, который получает от пользователя команды, что сделать с базой данных, и выполняет их. Эти-то команды и написаны на языке SQL.

SQL — декларативный язык. Это значит, что при написании кода мы говорим, что хотим получить от программы. Логика того, как именно СУБД будет выполнять поставленную задачу, скрыта от нас.

Конечно, если вы хотите сделать свои запросы более быстрыми и эффективными или обезопасить базы данных, знать алгоритмы СУБД полезно. Но даже не разбираясь в этих тонкостях, вы сможете писать на SQL.

Все SQL-команды делятся на четыре вида:

  • DDL (Data Definition Language, или язык описания данных). Их используют, чтобы создавать, изменять и удалять целые таблицы.
  • DML (Data Manipulation Language, или язык управления данными). Их применяют к содержимому таблиц, чтобы создавать, изменять, удалять атрибуты и записи. Если нужно получить какую-то информацию из базы данных, то пользуются именно DML-операторами.
  • DCL (Data Control Language, или язык контроля данных). Они нужны, чтобы выдавать конкретным пользователям доступ к базам данных и отзывать его.
  • TCL (Transaction Control Language, или язык контроля транзакций). Позволяет управлять транзакциями. Транзакция — это набор из нескольких команд, которые выполняются поочерёдно. Если одна из команд внутри транзакции не срабатывает, то все уже совершённые действия отменяются. То есть транзакция может быть совершена либо полностью, либо никак.

Где применяют SQL

В индексе TOPDB популярность СУБД определяется по тому, как часто их гуглят. В декабре 2022 года первые пять мест в нём занимают именно реляционные СУБД — вместе они дают больше 70% поисковых запросов.

Рейтинг DB-Engines даёт похожие цифры. В декабре 2022 года доля реляционных СУБД составляет 71,7%.

Без баз данных не будет ни сайтов, ни сетевых приложений, ни крупных информационных систем — нужно же где-то хранить всю информацию. При этом реляционных БД — большинство, а чтобы управлять ими, нужен SQL. Поэтому мало какая вакансия бэкенд-разработчика обходится без требования владеть SQL. По крайней мере, мы такой не нашли.

Но умение работать с базами данных пригодится не только программисту.

Аналитики данных напрямую работают с «сырой» информацией. Чем лучше и свободнее они общаются с БД, тем проще им добывать и обрабатывать нужные данные в нужном виде.

Маркетологам SQL тоже будет полезен для решения аналитических задач.

Тестировщикам понадобится обращаться к БД, потому что это важный компонент любого информационного продукта.

Руководители, менеджеры и бизнес-консультанты благодаря информации из БД смогут лучше понимать, как функционирует их бизнес, и принимать более взвешенные решения.

Как работать с SQL: основные операторы

Запросы в SQL похожи на естественный английский язык и выглядят как полноценные предложения.

Например, если мы захотим в базе данных нашей строительной фирмы получить номер телефона ООО «Коттеджи», нам нужно написать такую команду:

Также в SQL существуют агрегатные функции. Они позволяют производить с данными дополнительные операции и указываются вместо атрибутов. Агрегатные функции записываются в формате FUNCTION(ATTRIBUTE).

Вот некоторые из них.

COUNT — считает количество записей в колонке.

SUM — складывает содержимое значений колонки.

MIN — указывает на минимальное значение в колонке.

MAX — указывает на максимальное значение в колонке.

AVG — считает среднее значение в колонке.

ROUND — округляет значение в колонке.

Для работы с инструкциями, которые содержат агрегатные функции, есть специальные операторы.

GROUP BY — группирует выходные значения для колонок, к которым применили агрегатную функцию.

HAVING — работает как WHERE, но может применяться к агрегатным функциям.

Конечно, это далеко не все операторы, функции и ключевые слова, которые есть в SQL. Но уже этот набор даёт широкие возможности для работы с базами данных.

Что запомнить

  • SQL — это язык программирования для работы с реляционными базами данных.
  • Самые распространённые базы данных — реляционные. Их можно представить как набор двумерных таблиц, связанных друг с другом ключами.
  • SQL обращается к базам данных не напрямую, а через системы управления базами данных, илиСУБД.
  • Производители СУБД пишут для языка SQL собственные расширения — диалекты. Но базовый синтаксис у всех них одинаковый.
  • SQL-запросы состоят из операторов и складываются в полноценные предложения, которые похожи на естественный английский язык.

Больше интересного про код в нашем телеграм-канале. Подписывайтесь!

SQL для всех: зачем его учить?

Елизавета Свитанько – SQL для всех: зачем его учить?

Время на прочтение: 2 минут(ы) Знание языка SQL требуется в вакансиях аналитика, продакт-менеджера, а иногда даже маркетолога. В этой статье расскажем, что это такое и почему язык так популярен.

SQL для всех: зачем его учить?

Профессия: Аналитик данных
Время на прочтение: 2 минут(ы)

SQL (Structured Query Language) – язык структурированных запросов, стандартизированный язык для извлечения, обновления, добавления и удаления данных. С его помощью управляют реляционными базами данных (наборами данных с определенными связями между ними), пишут запросы в БД (например, «найди e-mail клиентов с именем Михаил»).

C помощью языка SQL мы можем “общаться” с базами данных так же, как взаимодействуем человеческим языком с другими людьми.

Для чего пригодится SQL?

Возможность «общения» с БД не безгранична. Представьте, что обученной собаке дали команду, которую она не знает, или слишком сложную задачу. Так и базы данных, понимают узкий перечень запросов. Чаще всего, с помощью SQL решают следующие задачи.

Извлечение данных

Допустим, в вашей БД контакты 10 000 клиентов, и задача найти все контакты, которые добавлены в базу данных 25 февраля. С помощью SQL это получится сделать быстрее, чем вручную.

Изменение данных

Мы нашли контакты, добавленные 25 февраля, но оказалось, что произошел сбой и в выборку попали 5000 лишних пользователей. SQL поможет быстро исправить ошибки на огромном массиве данных. Но будьте осторожны! Внося изменения в базе размером 20 000 контактов, легко наделать еще больше ошибок.

Добавление данных

SQL помогает быстро добавлять в базу большие объемы информации. Например, вам потребовалось загрузить 20 000 контактов конкурентов для дальнейшего анализа. Делать это с помощью SQL быстрее и приятнее!

Аналитик данных

Научитесь работать с большими данными и освойте востребованную профессию. Освоите SQL, Python, алгоритмы Big Data и машинного обучения

Почему именно SQL?

Популярный вопрос: зачем использовать SQL для аналитики, когда есть другие инструменты: Excel и Google-таблицы, Яндекс Метрика и Google Analytics, Tableau.

Слишком много информации

Приложения и сайты собирают терабайты данных о пользователе, а когда пользователей 50 000 или 500 000, то перечисленные инструменты могут не справиться (в том же Excel ограничено количество строк).

Проверяем слишком сложную гипотезу

Например, аналитику дали задачу получить данные, соответствующие сразу 10-20 условиям, и далеко не все сервисы подходят для такой задачи.

Быстрее

Чем больше и сложнее задача по сбору аналитики, тем больше времени занимает процесс настройки. К счастью, SQL справляется со всем этим гораздо быстрее!

Чувствительные данные

Некоторые данные не получится загрузить для корректного анализа в системе аналитики. Например, банковские транзакции (представьте, сколько их совершается ежедневно), работать с ними в Excel или Google Analytics будет проблематично.

Компании не используют конкретный инструмент

В одной компании используют Google Analytics, в другой — Яндекс Метрику, а SQL универсален и применим везде.

Валидация данных

Иногда отчеты в других системах аналитики выглядят подозрительно (например, сильная и неожиданная просадка посетителей сайта). С помощью SQL можно быстро проверить, все ли показатели учтены корректно, или же при формировании отчета произошел сбой.

Скорость, скорость, еще раз скорость

Продакт-менеджеру или маркетологу приходится оперативно добывать данные, чтобы проверить гипотезу. Самому написать 2-3 запроса гораздо быстрее, чем просить аналитика.

Работа с первичными данными

Взаимодействовать с необработанными данными полезно для понимания процессов компании. Работая только с готовыми отчетами, вы рискуете потерять информацию, которая хранится в БД. Зная, какие данные о пользователе собираете, легче строить и проверять гипотезы.

Что такое MySQL, PostgreSQL SQLite?

Часто новичков ставят в тупик такие аббревиатуры как MySQL PostgreSQL, SQLite. Это варианты систем управления реляционными базами данных (СУБД), которые используют компании в своих продуктах. Представьте их как различные инструменты: у каждой свои преимущества и нюансы работы, отличается функционал. Главное, все из них понимают базовые команды SQL, а значит, знать типы запросов важно каждому аналитику, продакт-менеджеру и даже маркетологу.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *