S q l: Основные команды SQL, которые должен знать каждый программист

Microsoft SQL Server Standard Edition в Санкт-Петербурге

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

 

Ядро СУБД SQL Server 

• Возобновляемая перестройка индексов в подключенном режиме: позволяет возобновить эту операцию с момента остановки после сбоя.
• Новое поколение функций обработки запросов, использующих стратегии оптимизации для адаптации к среде выполнения рабочих нагрузок приложений: адаптивные соединения в пакетном режиме, обратная связь по временно предоставляемому буферу памяти в пакетном режиме и выполнение с чередованием для многооператорных функций с табличными значениями.
• Автоматическая настройка базы данных предоставляет сведения о возможных проблемах с обработкой запросов и рекомендуемые решения.
• Новые возможности для баз данных графов, предназначенные для моделирования связей «многие ко многим».
• Инструмент Database Tuning Advisor (DTA) получил дополнительные функции и более высокую производительность.
• Усовершенствования работы в памяти включают поддержку вычисляемых столбцов в оптимизированных для памяти таблицах, а также полную поддержку функций JSON и оператор CROSS APPLY для модулей, скомпилированных в собственном коде.
• Службы SQL Server Integration Services (SSIS)
• SQL Server Integration Services (SSIS) теперь поддерживает SQL Server на Linux, и новый пакет позволяет апускать пакеты SSIS в Linux из командной строки.
• Новый компонент Scale Out для SSIS значительно упрощает запуск SSIS на множестве компьютеров. 
• Источник OData и диспетчер подключений OData теперь поддерживают подключение к веб-каналам OData в Microsoft Dynamics AX Online и Microsoft Dynamics CRM Online.
• Службы SQL Server Master Data Services (MDS)
• Обновление с SQL Server 2012, SQL Server 2014 или SQL Server 2016 до SQL Server  Master Data Services обеспечит улучшенную производительность и усовершенствованный интерфейс.
• Использование хранимой процедуры позволило значительно ускорить промежуточную обработку миллионов записей.
• Службы SQL Server Analysis Services (SSAS)
• SQL Server Analysis Services  включает множество улучшений для табличных моделей. К ним относятся следующие объекты.
• Табличный режим стал параметром установки по умолчанию для Analysis Services.
• Безопасность на уровне объектов для защиты метаданных табличных моделей.
• Возможность легко создавать связи на основе полей дат.
• Новые источники получения данных (Power Query) и поддержка существующих источников данных DirectQuery для запросов на языке M.
• Редактор DAX для SSDT.
• Подсказки по кодированию — продвинутая функция для оптимизации обновления данных больших табличных моделей в памяти.
• Современный интерфейс получения данных для табличных моделей с уровнем совместимости 1400.

Машинное обучение в SQL Server 

• Разработчикам в SQL Server теперь доступны обширные библиотеки машинного обучения и искусственного интеллекта для Python в экосистеме открытого кода, а также последние инновации от Майкрософт.
• Revoscalepy – этот эквивалент RevoScaleR (Python) включает параллельные алгоритмы для линейных и логистических регрессий, деревьев решений, усиленных деревьев и случайных лесов, а также обширный набор API для преобразования и перемещения данных, контекстов удаленного вычисления и источников данных.
• Microsoftml –  этот современный пакет алгоритмов и преобразований для машинного обучения с привязками Python включает инструменты работы с глубокими нейронными сетями, быстрыми деревьями и лесами принятия решений, а также оптимизированные алгоритмы линейной и логистической регрессии. 
• Управление пакетами – T-SQL теперь поддерживает оператор CREATE EXTERNAL LIBRARY, который предоставляет администраторам баз данных больше возможностей для управления с помощью пакетов R. 

Новое в версии Microsoft SQL Server 2019:

• Возможность анализировать каждый тип данных.  Запросив реляционные, нереляционные, структурированные и неструктурированные данные, пользователь получает информацию из всех данных и получает полную картину бизнеса со встроенным Apache Spark.
• Такие функции, как интеллектуальная обработка запросов и поддержка устройств постоянной памяти, позволяют SQL Server улучшать производительность и масштабируемость всех рабочих нагрузок базы данных без внесения изменений в приложение или структуру.
• Выбор платформы и языка. гибкость в использовании языка и платформы на выбор с поддержкой открытого исходного кода. Возможный запуск SQL Server в контейнерах Linux с поддержкой Kubernetes или в Windows.
• Преимуществами масштабируемости и производительности повышают стабильность и время отклика базы данных без внесения изменений в приложение. Высокая доступность для критически важных приложений и хранилищ данных.
•  Кластеры больших данных. Они предоставляют ключевые элементы – распределенную файловую систему Hadoop (HDFS), Apache Spark и инструменты аналитики, глубоко интегрированные с SQL Server и полностью поддерживаемые Microsoft.
•  Простое развертывание базы данных с использованием контейнеров Linux в кластере Kubernetes.

Amazon RDS для SQL Server – Amazon Web Services (AWS)

SQL Server – это система управления реляционными базами данных, разработанная корпорацией Microsoft. Amazon RDS for SQL Server упрощает настройку, эксплуатацию и масштабирование развертываний SQL Server в облаке. Amazon RDS поможет за считаные минуты выполнить развертывание множества выпусков SQL Server (2012, 2014, 2016, 2017 и 2019), включая выпуски Express, Web, Standard и Enterprise, и сэкономить средства благодаря масштабированию вычислительных ресурсов. Amazon RDS способен решить множество трудоемких задач по управлению базой данных: выделение ресурсов, создание резервных копий, обновление ПО, мониторинг и масштабирование аппаратных ресурсов. Это позволяет нашим клиентам полностью сосредоточиться на разработке приложений.

Amazon RDS для SQL Server поддерживает модель лицензирования «лицензия включена». Отдельно приобретать лицензии Microsoft SQL Server не требуется. При оплате по модели с включенной лицензией в цену входит стоимость программного обеспечения, базовых аппаратных ресурсов и возможностей управления Amazon RDS.

При этом взимается почасовая плата без авансовых платежей или каких-либо долговременных обязательств. Кроме того, вы можете также купить зарезервированные инстансы баз данных на один год или на три года. Используя зарезервированные инстансы баз данных, вы однократно вносите небольшой авансовый платеж за каждый из них, а затем платите почасовую плату с большой скидкой, что позволяет сэкономить до 65 % средств.

Инстансы БД SQL Server сервиса Amazon RDS могут быть выделены либо со стандартным хранилищем, либо с хранилищем с выделенными ресурсами ввода-вывода. Amazon RDS Provisioned IOPS – это вариант хранения, предназначенный для обеспечения быстрой, предсказуемой и последовательной производительности ввода‑вывода и оптимизированный для рабочих нагрузок транзакционных (OLTP) баз данных с большим количеством операций ввода‑вывода.

НОУ ИНТУИТ | Основы SQL

Форма обучения:

дистанционная

Стоимость самостоятельного обучения:

бесплатно

Доступ:

свободный

Документ об окончании:

Уровень:

Для всех

Длительность:

16:15:00

Студентов:

32215

Выпускников:

3345

Качество курса:

4. 06 | 3.65

Развернутое введение в SQL на основе стандарта SQL:1999. Обсуждаются типы данных, допускаемые в SQL; средства определения объектов базы данных; манипулирование данными; управление соединениями, сессиями и транзакциями; обеспечение безопасности; динамический и встроенный SQL.

На сегодняшний день (и в обозримом будущем) язык SQL является единственным признанным стандартом языка баз данных, поддерживаемым всеми основными поставщиками СУБД. С годами (а история SQL насчитывает уже около 30 лет) язык развивается и усложняется. Хорошее владение языком SQL является обязательным для профессиональных разработчиков приложений баз данных и их администраторов. Данный курс основан на последнем международном стандарте SQL:1999, хотя не охватывает все аспекты языка. В курс включены темы, являющиеся, во-первых, наиболее важными для пользователей и разработчиков приложений и, во-вторых, наиболее проработанными в текущей версии стандарта. Во вводной части курса обсуждаются история языка, его основные концепции, типы данных, допустимые в SQL. Приводится обзор подходов SQL к определению данных и манипулированию ими. В основной части последовательно обсуждаются следующие темы: значения, базовые функции и выражения SQL; арифметические выражения с переключателями и преобразованием типа, выражения со строковыми значениями; виды предикатов, допустимых в логических выражениях; соединения и теоретико-множественные операции; виды выражений запросов; ограничения целостности и ссылочная целостность; триггеры; встроенный SQL и язык модулей; принципы работы с курсорами; привилегии, пользователи и безопасность; управление транзакциями; управление соединениями и удаленный доступ к базам данных; хранимые процедуры и функции; динамический SQL; интерфейс уровня вызовов; диагностика и управление ошибочными ситуациями; вопросы интернационализации и локализации; информационная схема.

ISBN: 978-5-9556-0101-4

Теги: BOF, isolation level, java, READ COMMITTED, sql, администрирование, базы данных, безопасность, динамический sql, драйверы, клиенты, кортеж отношения, ограничение внешнего ключа, ограничения целостности данных, потенциальный ключ, приложения, процедуры, реляционные базы данных, серверы, сортировка, статический sql, телефоны, теория, уровень изоляции, целостность, элементы

Предварительные курсы

Дополнительные курсы

2 часа 30 минут

—

Введение в структурированный язык запросов SQL

Дается определение структурированного языка запросов SQL. Вводится понятие базы данных, реляционной базы данных, СУБД. Определяется место языка SQL в разработке информационных систем, организованных на основе технологии клиент-сервер. Приводится классификация команд SQL: определение структуры базы данных, манипулирование данными, выборка данных, управление данными, команды администрирования данных и управления транзакциями. Дается описание учебной базы данных.

—

Определение структуры данных

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

—

Создание базы данных и проектирование таблиц

Определяется процесс создания базы данных. Описываются операторы
создания, изменения базы данных. Рассматривается возможность указания
имени файла или нескольких файлов для хранения данных, размеров и
местоположения файлов. Анализируются операторы создания, изменения,
удаления пользовательских таблиц. Приводится описание параметров для
объявления столбцов таблицы. Дается понятие и характеристика
индексов. Рассматриваются операторы создания и изменения индексов.
Определяется роль индексов в повышении эффективности выполнения
операторов SQL.

—

Эффективное выполнение запросов для извлечения данных

Дается синтаксис оператора SELECT. Описываются предложение FROM и
использование синонимов. Определяется построение условий выбора
данных с применением операторов сравнения, логических операторов IS
NULL, BETWEEN, IN, LIKE и логических связок OR и AND. Предлагаются
способы использования оператора ORDER BY для сортировки записей в
запросах выборки.

—

Соединения и теоретико-множественные операции над отношениями

Рассматриваются специальные операции над отношениями: выборка, проекция, декартово произведение, соединение. Приводятся различные типы соединений: соединение по эквивалентности, естественное, внешнее соединение, полусоединение. Операции над отношениями иллюстрируются на примерах оператора SELECT. Рассматриваются примеры выбора данных из нескольких таблиц. Приводится объединение результатов нескольких запросов.

—

Вычисления и подведение итогов в запросах

Описывается использование арифметических операторов и построение вычисляемых столбцов. Рассматриваются итоговые (агрегатные) функции COUNT, SUM, AVG, MAX, MIN. Дается пример использования оператора GROUP BY для группировки в запросах выборки данных. Описывается применение предложения HAVING.

—

Построение нетривиальных запросов

Дается определение подзапроса. Приводятся примеры формирования вложенных подзапросов. Показывается способ построения подзапросов, возвращающих множественные и единичные значения с использованием операторов EXISTS, ALL, ANY.

—

Запросы модификации данных

Рассматриваются запросы модификации данных в реляционной таблице: вставка отдельной записи INSERTѕ VALUESѕ или группы записей из имеющейся таблицы INSERTѕ SELECTѕ, удаление записей по условию DELETE, изменение записей по условию UPDATE. Вводится понятие целостности данных. Определяются целостность сущностей и ссылочная целостность.

—

Определение ограничений целостности

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

—

Представления

Дается понятие представлений. Определяется роль представлений в вопросах безопасности данных. Описывается процесс управления представлениями: создание, изменение, применение, удаление представлений.

—

Функции пользователя

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

—

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

Определяется понятие хранимых процедур. Приводятся
примеры создания, изменения и использования хранимых процедур с
параметрами. Дается определение входных и выходных параметров.
Приводятся примеры создания и вызова хранимых процедур.

—

Курсоры: принципы работы

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

—

Триггеры: создание и применение

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

—

Триггеры в рекурсивных структурах

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

—

Транзакции и блокировки

Приводится определение транзакции и ее свойств; представлены явные, неявные, автоматические и вложенные транзакции. Описываются средства обработки и управления транзакциями. Рассматривается механизм сохранения и отката транзакций. Вводится понятие параллельности в работе базы данных и методы управления параллельностью с использованием блокировок. Приводится описание уровней блокировок и уровней изоляции сервера. Выделяются основные и специальные типы блокировок.

—

Основные методы защиты данных. Управление пользователями

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

—

Внедрение SQL-операторов в прикладные программы

Описываются возможности использования языка SQL в прикладных программах. Определяется роль технологии ODBC как единого интерфейса для доступа к смешанным базам данных SQL. Рассматриваются архитектура ODBC и варианты доступа к базам данных с использованием технологии ADO и Java. Методы доступа иллюстрируются примерами.

—

Поиск информации в тексте средствами MS SQL Server — Разработка на vc.ru

{«id»:210060,»url»:»https:\/\/vc.ru\/dev\/210060-poisk-informacii-v-tekste-sredstvami-ms-sql-server»,»title»:»\u041f\u043e\u0438\u0441\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0432 \u0442\u0435\u043a\u0441\u0442\u0435 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0430\u043c\u0438 MS SQL Server»,»services»:{«facebook»:{«url»:»https:\/\/www. facebook.com\/sharer\/sharer.php?u=https:\/\/vc.ru\/dev\/210060-poisk-informacii-v-tekste-sredstvami-ms-sql-server»,»short_name»:»FB»,»title»:»Facebook»,»width»:600,»height»:450},»vkontakte»:{«url»:»https:\/\/vk.com\/share.php?url=https:\/\/vc.ru\/dev\/210060-poisk-informacii-v-tekste-sredstvami-ms-sql-server&title=\u041f\u043e\u0438\u0441\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0432 \u0442\u0435\u043a\u0441\u0442\u0435 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0430\u043c\u0438 MS SQL Server»,»short_name»:»VK»,»title»:»\u0412\u041a\u043e\u043d\u0442\u0430\u043a\u0442\u0435″,»width»:600,»height»:450},»twitter»:{«url»:»https:\/\/twitter.com\/intent\/tweet?url=https:\/\/vc.ru\/dev\/210060-poisk-informacii-v-tekste-sredstvami-ms-sql-server&text=\u041f\u043e\u0438\u0441\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0432 \u0442\u0435\u043a\u0441\u0442\u0435 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0430\u043c\u0438 MS SQL Server»,»short_name»:»TW»,»title»:»Twitter»,»width»:600,»height»:450},»telegram»:{«url»:»tg:\/\/msg_url?url=https:\/\/vc. ru\/dev\/210060-poisk-informacii-v-tekste-sredstvami-ms-sql-server&text=\u041f\u043e\u0438\u0441\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0432 \u0442\u0435\u043a\u0441\u0442\u0435 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0430\u043c\u0438 MS SQL Server»,»short_name»:»TG»,»title»:»Telegram»,»width»:600,»height»:450},»odnoklassniki»:{«url»:»http:\/\/connect.ok.ru\/dk?st.cmd=WidgetSharePreview&service=odnoklassniki&st.shareUrl=https:\/\/vc.ru\/dev\/210060-poisk-informacii-v-tekste-sredstvami-ms-sql-server»,»short_name»:»OK»,»title»:»\u041e\u0434\u043d\u043e\u043a\u043b\u0430\u0441\u0441\u043d\u0438\u043a\u0438″,»width»:600,»height»:450},»email»:{«url»:»mailto:?subject=\u041f\u043e\u0438\u0441\u043a \u0438\u043d\u0444\u043e\u0440\u043c\u0430\u0446\u0438\u0438 \u0432 \u0442\u0435\u043a\u0441\u0442\u0435 \u0441\u0440\u0435\u0434\u0441\u0442\u0432\u0430\u043c\u0438 MS SQL Server&body=https:\/\/vc.ru\/dev\/210060-poisk-informacii-v-tekste-sredstvami-ms-sql-server»,»short_name»:»Email»,»title»:»\u041e\u0442\u043f\u0440\u0430\u0432\u0438\u0442\u044c \u043d\u0430 \u043f\u043e\u0447\u0442\u0443″,»width»:600,»height»:450}},»isFavorited»:false}

Учебное пособие по SQL

SQL — стандартный язык для хранения, обработки и извлечения данных.
в базах данных.

Наш учебник по SQL научит вас использовать SQL в:
MySQL, SQL Server, MS Access, Oracle, Sybase, Informix, Postgres и другие системы баз данных.

Начните изучать SQL прямо сейчас »

Примеры в каждой главе

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

Щелкните кнопку «Попробуйте сами», чтобы увидеть, как это работает.

Упражнения SQL

Примеры SQL

Учись на примерах! Этот учебник дополняет все пояснения поясняющими примерами.

Просмотреть все примеры SQL

Тест-викторина по SQL

Проверьте свои навыки SQL в W3Schools!

Начать тест по SQL!

Ссылки на SQL

На W3Schools вы найдете полный справочник по ключевым словам и функциям:

Справочник по ключевым словам SQL

Функции MYSQL

Функции SQLServer

Функции доступа MS

Краткий справочник по SQL

Типы данных SQL

Типы данных и диапазоны для Microsoft Access, MySQL и SQL Server.

Типы данных SQL

Экзамен по SQL — получите диплом!

Интернет-сертификация W3Schools

Идеальное решение для профессионалов, которым необходимо совмещать работу, семью и карьеру.

Уже выдано более 30 000 сертификатов!

Получите сертификат »

Сертификат HTML документирует ваши знания HTML.

Сертификат CSS документирует ваши знания в области CSS.

Сертификат JavaScript документирует ваши знания JavaScript и HTML DOM.

Сертификат Python документирует ваши знания Python.

Сертификат Data Science Certificate документирует ваши знания в области Data Science.

Сертификат jQuery подтверждает ваши знания о jQuery.

Сертификат SQL документирует ваши знания SQL.

Сертификат PHP подтверждает ваши знания PHP и MySQL.

Сертификат Java документирует ваши знания Java.

Сертификат XML документирует ваши знания XML, XML DOM и XSLT.

Сертификат Bootstrap документирует ваши знания о среде Bootstrap.

SQL: что это такое?

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

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

Что такое SQL?

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

Много информации можно скомпилировать в электронную таблицу, такую ​​как Microsoft Excel, но SQL предназначен для компиляции и управления данными в гораздо больших объемах. В то время как электронные таблицы могут стать громоздкими из-за слишком большого количества информации, базы данных SQL могут обрабатывать миллионы или даже миллиарды ячеек данных.

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

Как работает изучение SQL

Язык структурированных запросов проще, чем другие более сложные языки программирования. Как правило, новичкам легче изучить SQL, чем им освоить такие языки, как Java, C ++, PHP или C #.

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

История SQL

История SQL насчитывает более полувека. В 1969 году исследователь IBM Эдгар Ф. Кодд определил модель реляционной базы данных, которая стала основой для разработки языка SQL. Эта модель построена на общих порциях информации (или «ключах»), связанных с различными данными. Например, имя пользователя может быть связано с настоящим именем и номером телефона.

Несколько лет спустя IBM начала работу над новым языком для систем управления реляционными базами данных, основанным на открытиях Кодда.Первоначально этот язык назывался SEQUEL, или язык структурированных английских запросов. Названный System R, проект претерпел несколько реализаций и изменений, и название языка менялось несколько раз, прежде чем окончательно перейти на SQL.

После начала тестирования в 1978 году IBM приступила к разработке коммерческих продуктов, включая SQL / DS (1981) и DB2 (1983). Другие производители последовали их примеру, объявив о своих собственных коммерческих предложениях на основе SQL. К ним относятся Oracle, выпустившая свой первый продукт в 1979 году, а также Sybase и Ingres.Взаимодействие с другими людьми

SQL в действии: MySQL

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

Рассмотрим музыкальную программу, такую ​​как iTunes, в которой хранится музыка по исполнителям, песням, альбомам, спискам воспроизведения и т. Д. Как пользователь, вы можете искать музыку по любому из этих и других параметров, чтобы найти то, что ищете.Чтобы создать подобное приложение, вам понадобится программное обеспечение для управления вашей базой данных SQL, и это то, что делает MySQL.

Требуемые навыки SQL

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

Некоторые должности, требующие навыков SQL, включают:

• Администратор базы данных (DBA ): это тот, кто специализируется на обеспечении правильного и эффективного хранения данных и управления ими.Базы данных наиболее ценны, когда они позволяют пользователям быстро и легко извлекать желаемые комбинации данных.
• Инженер по миграции баз данных : Этот человек специализируется на перемещении данных из различных баз данных на сервер SQL.
• Специалист по анализу данных : Эта должность очень похожа на должность аналитика данных, но ученым по данным обычно поручено обрабатывать данные в гораздо больших объемах и накапливать их с гораздо большей скоростью.
• Архитектор больших данных : Кто-то в этой роли создает продукты для обработки больших объемов данных.

Ключевые выводы

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

Учебное пособие по SQL для анализа данных | Basic SQL

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

В частности, это руководство предназначено для начинающих аналитиков, которые немного использовали Excel, но не имеют опыта программирования.

В этом уроке мы рассмотрим:

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

Как работает учебник SQL для анализа данных

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

Примечание. Чтобы начать обучение, вам потребуется учетная запись пользователя режима.Вы можете подписаться на него на mode.com.

Что такое SQL?

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

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

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

Как произносится SQL?

Понятия не имею.

Что такое база данных?

Из Википедии: База данных — это организованный набор данных.

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

Если вы использовали Excel, вы уже должны быть знакомы с таблицами — они похожи на электронные таблицы. В таблицах есть строки и столбцы, как в Excel, но они немного более жесткие. Например, таблицы базы данных всегда организованы по столбцам, и каждый столбец должен иметь уникальное имя. Чтобы получить представление об этой организации, на изображении ниже показан образец таблицы, содержащей данные о церемонии вручения награды Оскар 2010:

В целом, в базах данных таблицы организованы в схемы. В Mode мы организуем таблицы вокруг пользователей, которые их загружают, поэтому у каждого человека есть своя собственная схема. Схемы определяются именами пользователей, поэтому, если ваше имя пользователя — databass3000, все загружаемые вами таблицы будут храниться в схеме databass3000.Например, если databass3000 загружает таблицу продаж корма для рыбы под названием fish_food_sales , эта таблица будет иметь ссылку как databass3000.fish_food_sales . Вы заметите, что все таблицы, используемые в этой серии руководств, имеют префикс «учебник». Это потому, что они были загружены учетной записью с таким именем пользователя.

Вы в пути!

Теперь, когда вы знакомы с основами, пора погрузиться в изучение SQL.

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

Без хороших технологий весь мировой маркетинг не поможет компании сдвинуться с мертвой точки и удержать ее в воздухе, и, наоборот, без хорошего маркетинга и продаж все технологии в мире тоже этого не сделают. .За многие десятилетия наблюдения за ИТ-сектором здесь, на сайте The Next Platform , у нас всегда было это бинокулярное видение, наблюдая за технологиями и рынками, которые они преследуют. Мы всегда говорили с обоими лагерями: технологиями и маркетингом.

В последние годы мы провели кучу времени с техниками в Cockroach Labs, особенно со Спенсером Кимбаллом, соучредителем и главным исполнительным директором компании, особенно когда ее распределенная реляционная база данных SQL, вдохновленная гаечным ключом Google, вышла из строя. stealth в феврале 2017 года и снова в последнее время, когда Кимбалл говорил о том, как CockroachDB может противостоять действующим реляционным базам данных, в частности Oracle, в июле 2019 года.

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

Гуагенти — необычный менеджер по маркетингу в том смысле, что он был по обе стороны стола переговоров. Гуагенти был веб-мастером журнала People , поскольку он начал свою карьеру еще в первые дни бума доткомов, когда коммерческая всемирная паутина была блестящей и новой, и в итоге попал в несколько рекламных агентств, которые были приобретены такими крупными игроками, как Razorfish и Omnicom.Затем он перешел в Accenture и Cap Gemini, чтобы разрабатывать продукты и маркетинговую стратегию после краха dot-come, вернулся на несколько лет в Razorfish, чтобы управлять рекламными технологиями с книгой о бизнесе на 120 миллионов долларов, а затем перешел на программное обеспечение. управление продуктами и маркетинг в Acquia (один из первых поставщиков PaaS), Nginx (сервер веб-приложений), Mesosphere (платформа, проигравшая Kubernetes) и MemSQL (один из первых поставщиков распределенных баз данных SQL, а теперь и его конкурент).

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

Тимоти Прикетт Морган: Что насчет баз данных делает их идеальным местом для работы прямо сейчас? Я тоже это чувствую, и поэтому прошлым летом мы провели мероприятие The Next Database Platform , но я хочу услышать ваш ответ.

Питер Гуагенти: Последнее десятилетие я занимался стартапами в области программного обеспечения. Я был в разработке с самого начала, и когда я перешел на Nginx, меня взволновали данные. Если вы действительно думаете об эволюции приложений, когда мы впервые начали оптимизировать бизнес-процессы и превратить их в программное обеспечение, все дело в данных. А затем в конце 1990-х — начале 2000-х годов занял место Интернет, и на самом деле речь шла не о данных. Может быть, дело было в контенте и других вещах. Но по большей части это не были приложения, интенсивно использующие данные. Это был опыт.

TPM: Это были приложения, интенсивно использующие пользовательский интерфейс. Многие люди сталкиваются с простыми вещами. Это было достаточно сложно и потребовало гипермасштабирования, которого мы никогда не видели.

Питер Гуагенти: Интенсивный пользователь — это отличный способ описать это.Затем с Web 2.0 мы перешли от интенсивного использования пользователем к интенсивному использованию данных, и все действительно начало двигаться в сторону данных. Мы видели рост Facebook, Google и других, которые научились использовать данные — много данных — для получения конкурентного преимущества. Некоторые утверждают, что использовать данные как оружие. Поэтому, когда я искал путь для себя там, где я хотел быть, я сосредоточился на данных, потому что чувствовал, что именно здесь будут происходить самые интересные вещи.

Если вы посмотрите на данные о расходах на ИТ от Gartner, данные в самом широком смысле являются самой большой категорией.Они оценивают рынок примерно в 70 миллиардов долларов в ближайшие несколько лет. Примерно две трети этой суммы составляют транзакционные данные.

TPM: Какие еще данные, если они не транзакционные? Аналитический?

Питер Гуагенти: Типа. Я думаю, что Gartner смотрит на это как на исторические и аналитические вместе, а также как на операционные и транзакционные вместе, как на два общих класса данных, которые появляются сейчас.

TPM: Я думал, что транзакции — это гораздо меньшая часть пирога.

Питер Гуагенти: Интересно, что это не так. С данными IoT есть много операционных данных — только аналитические датчики и тому подобное. А о большинстве транзакционных вещей мы просто не задумываемся, потому что это просто происходит. Все банковские системы, все системы CRM, все коммерческие и розничные приложения. Мы ожидаем, что это будет просто работать.

TPM: Я начал с мэйнфреймов IBM и миникомпьютеров IBM AS / 400, систем записи, хранящих транзакционные данные, а затем на протяжении десятилетий наблюдал, как этот транзакционный мир стал аналитическим.Это стало хранилищем данных или обслуживанием OLAP, что было признанием того, что в мире недостаточно денег для выполнения этой работы на мэйнфрейме или миникомпьютере. У меня создалось впечатление, что разрыв между транзакционными и аналитическими данными становился все больше и больше, и что транзакционный материал был супертонким и очень дорогим слоем.

Питер Гуагенти: На самом деле все идет по другому пути. Дело обстоит совсем иначе.

TPM: Я не могу быть единственным, кто придерживается этого заблуждения, поэтому я рад, что мы ведем этот разговор.

Питер Гуагенти: Вы определенно не один такой. Я думаю, что это одна из тех вещей, когда мы все думаем о данных как о монолитной части ИТ-организации. Но мы не задумываемся о нюансах, связанных с данными, или не думаем о их важности. Например, если ваш доступ к средству развертывания прерывается, вам придется делать что-то вручную, но это еще не конец света, верно? Если ваша база данных выходит из строя, это конец вашего мира .Это. совсем проблема.

Мы находимся при этом интересном стечении обстоятельств. Все переходит в облако, поэтому каждая организация в мире переосмысливает весь свой стек. Цифровая трансформация резко ускорилась благодаря пандемии коронавируса — то, что мы видели за последние девять месяцев, является таким же большим изменением в цифровой сфере, как и последние девять лет трансформации. Сейчас данные — это сердце каждого бизнеса и приложения. У нас всегда были транзакционные и аналитические данные внутри организаций.У нас также был рост Интернета, просто данные приложений — подумайте о вещах, которые будут жить в базе данных NoSQL. Это действительно как раз про то приложение, интенсивно использующее пользователя, о котором мы говорили выше.

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

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

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

TPM: Или так в некоторых случаях, и я сам делал это вокруг своей собственной инфраструктуры, потому что после десяти лет эксплуатации они приходят к одному дню и думают: «Я не хочу делать это любой больше ». Я не этим занимаюсь. В этот момент, даже при более высоких затратах, возникает вопрос: опаснее ли управлять своим собственным центром обработки данных, чем использовать их? Мне было нетрудно догадаться, что это так, и когда затраты выровнялись, я вообще не принимал решения.Решение принял я.

Питер Гуагенти: Отличный момент. Если вы один из крупных банков, на самом деле центры обработки данных являются частью вашего конкурентного преимущества. Вы думаете об алгоритмических торговых системах и тому подобном. У них есть компьютерщики и инженеры, которые конкурируют с волшебниками, которые есть у Google, и они, вероятно, зарабатывают больше денег, чем платит Google. В этом случае центр обработки данных является частью вашей основной бизнес-модели. Но если вы крупный производитель, производитель или продавец среднего размера, по сравнению с ним вы уже плохо разбираетесь в этом, так зачем вам продолжать?

Итак, в мире данных данные приложений сначала отправлялись в облако в начале 2000-х годов, и это были приложения на AWS, прикрепляемые к корзинам S3.Вторая волна представляла собой аналитические данные, потому что у них было ограниченное количество пользователей, ограниченный объем параллелизма, а обслуживание локально было слишком дорогостоящим из-за размера данных. Итак, мы увидели, как взорвался Redshift, мы увидели взрыв BigQuery. И затем вы в конечном итоге видите Snowflake, который является своего рода образцом перемещения аналитических данных в облако, потому что он работает в потоковом режиме, он работает со всем, что вас действительно волнует. И если вы являетесь ИТ-директором и у вас есть все эти устаревшие системы, такие как Teradata или Netezza, у которых закончился срок службы, переходить на эти службы обработки данных было несложно из-за ограниченного числа пользователей. И как только выйдет Snowflake, у них может быть мультиоблако, и их не будут приковывать наручниками к поставщику, как к Oracle. Они могли натравить каждое из этих облаков друг на друга.

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

TPM: Да ладно, они могут просто использовать Parallel Sysplex целую кучу из них, и все это будет просто гигантской кластерной базой данных. [Смех] Я посчитал. Вы могли бы — подождите. Неважно, это будет 100 миллионов долларов, а может быть, 250 миллионов долларов. Вы понимаете, что я шучу. Если бы это было правдой, Google работал бы на IBM Parallel Googleplex.

Peter Guagenti: Если вы крупный розничный банк с бизнесом на четырех континентах, это не сработает. В какой-то момент вы выжали из своих инвестиций в мэйнфрейм все, что могли. Розничная торговля и коммерция стремительно растут, и объем данных о транзакциях стремительно растет, потому что вместо группы дистрибьюторов они продают напрямую потребителю.И при этом ожидается нулевая задержка.

TPM: Ну, 200 миллисекунд, а не ноль, это точная продолжительность концентрации внимания и терпения человека в наши дни.

Питер Гуагенти: Я думаю, вы проявите щедрость на 200 миллисекунд [Смех]. Возможно, количество времени, которое нам нужно, чтобы моргнуть.

TPM: Итак, позвольте мне задать следующий вопрос. В Oracle, DB2, SQL Server и т. Д. Очень много транзакционных данных.Это твоя цель? Как вы думаете, сможете ли вы перемещать эти вещи внутри компании или в облаке? Как вы собираетесь, как вы собираетесь победить этих ребят и получить их деньги?

Питер Гуагенти: Это наша цель? Я бы сказал да и нет. И это не наша цель, это фокус наших клиентов. Позволь мне объяснить.

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

Я не разговариваю ни с одной компанией из списка Fortune 50, у которой нет 30 новых стратегических инициатив в своей повестке дня, и все они собираются включать новые приложения. Это наша рулевая рубка. Но эти новые приложения имеют те же требования и требования, что и другие критически важные системы, которые уже работают в бизнесе, потому что они обычно гиперподключены.Возможно, мы разрушим все эти монолиты, перейдем к большему количеству микросервисов или даже — не дай бог, мы больше не будем называть это так — сервисно-ориентированной архитектурой. Поэтому для этих приложений они ищут что-то, что является родным и современным для облачных вычислений, но им нужно что-то, что будет иметь такую ​​же согласованность, надежность и долговечность, которые они получают от традиционных систем, с которыми они работали десятилетиями.

Второе, что происходит — это модернизация.Многое из того, что работает на сервере Oracle, DB2 или SQL — давайте будем честными — было написано примерно во времена Web 1.0 или Web 2.0.

TPM: Некоторые из них были написаны, когда я был ребенком. Я помню, как SQL Server 200 был предпочтительным OLAP-сервером для многих предприятий, в том числе тех, которые были полностью и полностью посвящены IBM AS / 400 или мэйнфреймам для своих критически важных приложений. Это стоит намного меньше денег, чтобы сбросить это на Windows Server, SQL Server и дешевом сервере X86, и кого волнует, если он время от времени выйдет из строя.Его приобретение и эксплуатация обходились в пятую часть дешевле.

Peter Guagenti: Реальность такова, что даже на этих устаревших платформах этот материал постоянно меняется из-за его важности для бизнеса. Он всегда модифицируется. Так что сейчас мы часто видим не только новые разработки, но и модернизацию приложений. Возьмем крупного производителя, продающего напрямую потребителю, а не только через дистрибьюторов, я должен предъявить требования к этой внутренней системе, но эти системы не будут работать так, как я хочу.Мне нужно будет модернизировать это приложение, а затем добавить в него что-то новое. И тогда они начинают пристально смотреть на такие вещи, как Oracle и DB2, и спрашивают: ну а зачем мне продолжать строить на этой штуке? Почему бы мне не начать сокращать его, когда я начинаю сокращать рабочие нагрузки, которые ему противостоят, а не менять систему управления запасами, которая сегодня прекрасно работает на складе. Из-за чего пойти и возиться с этим. ИТ-директора отлично справляются с управлением портфелем. Куда я вкладываю, куда я деинвестирую, где я сохраняю стабильность? И поэтому многие из того, что происходит в базе данных, они смотрят и говорят: ну, я собираюсь сохранить это стабильным.Все нормально, не сломано. Мы оставим это в покое. Но эти новые требования потребуют новых систем, потому что они не будут работать должным образом.

И именно здесь, я думаю, мы наблюдаем это изменение в этой третьей волне технологий баз данных, а именно в этих распределенных реляционных базах данных SQL. Это не только CockroachDB. Это Google Spanner. Это Microsoft CosmosDB и другие.

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

TPM: Точно так же, как нам пришлось пройти виртуализацию сервера, чтобы добраться до контейнеров, может быть, нам нужно было пройти через NoSQL, чтобы добраться до распределенного SQL? Мы не знали, как это делать.И было много людей, которые пытались, но всегда приходилось идти на компромиссы с NoSQL. Я не верю, что в долгосрочной перспективе для NoSQL найдется место.

Питер Гуагенти: Я бы поспорил с этим для случаев использования легких приложений, когда вы просто работаете с объектами. NoSQL действительно работает очень хорошо. Но есть также аргумент, чтобы просто использовать простое хранилище, а не хранилище данных. С кем-то, кто пришел из опыта, с этим намного легче работать, потому что это ведро, верно? Я имею в виду, что я думаю об этом как о сортировке вещей на полу.

TPM: Я бы сказал, что MongoDB идеально подходит для этого?

Питер Гуагенти: Согласен.

TPM: MongoDB считает, что большая часть данных, которые генерируются в мире, могут быть сохранены в документе, и по праву должны и будут, а все остальное будет храниться в чем-то вроде CockroachDB. Они не заявляют, что хотят захватить весь мир.

Питер Гуагенти: Да, правда, но я думаю, что они могут пожалеть о своем решении.Если вы помните, они приводили тот же аргумент при первом запуске. Специалисты по связям с разработчиками MongoDB между 2010 и 2012 годами были известны тем, что говорили обо всем, что можно заменить. А потом люди пытаются, потому что они были защитниками и евангелистами, а данные были противоречивыми, и они что-то теряли. И вот они отступили.

TPM: Распределенные системы SQL действительно доступны, масштабируемы и относительно доступны. Готовы ли мы сейчас?

Питер Гуагенти: Трудно сказать, потому что вы не знаете того, чего не знаете.Но я думаю, что мы идем по этому пути уже 25 лет. Эту концепцию выстраивали давно. Я думаю, что мы наконец достигли такого уровня зрелости компьютерных наук и оборудования, что мы действительно можем сделать это реальностью. Так что, я думаю, мы собираемся, я думаю, мы начнем видеть некоторые урегулирования вокруг этого, потому что это то, для чего текущее состояние оборудования, с которым мы работаем, действительно оптимизировано.

TPM: Как обстоят дела с учетом всех этих изменений в Cockroach Labs?

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

Я присоединился к Cockroach Labs на третьей неделе марта 2020 года из MemSQL. Так что я стал первым сотрудником компании, подключившимся удаленно.И я помню, как мы, как команда руководителей, остановились и сказали: «Мы не знаем, что будет дальше». Мы просто не знаем. Вам нужно просто набраться терпения, продолжать поддерживать наших клиентов и продолжать делать все возможное, чтобы помочь им. Перенесемся на десять месяцев вперед, и у нас взрывной рост.

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

TPM: Это те кривые, которые использовались Nutanix и Pure Storage десять лет назад. Вы можете сделать мне одолжение? Сможете ли вы заработать деньги до того, как доживете до десяти лет? [Смех]

Питер Гуагенти: Ну, это всегда игра. И поэтому мы пока собрали 355,1 миллиона долларов. Оценка более чем в 2 миллиарда долларов — это довольно впечатляюще для компании нашего размера.Но на самом деле нет, мы не будем прибыльными, потому что посмотрите, против кого мы идем и что заменяем. Согласно одному из отчетов, которые я прочитал, треть всех расходов на ИТ приходилась на данные и системы данных. Третий . Так что мы собираемся продолжать собирать деньги и удваивать объемы НИОКР, потому что мы гонимся за таким размером рынка.

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

Машинное обучение предлагает свежий подход к устранению уязвимостей SQL-инъекций

Ученые используют обучение с подкреплением для автоматизации процесса эксплуатации SQLi.

ОБНОВЛЕНО Новый метод машинного обучения может упростить для тестировщиков на проникновение поиск эксплойтов SQL-инъекций в веб-приложениях.

Представленный в недавно опубликованной статье исследователей из Университета Осло, метод использует обучение с подкреплением для автоматизации процесса эксплуатации известной уязвимости SQL-инъекций.

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

Обучение с подкреплением

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

«Неизбежно, что ИИ и машинное обучение также применяются в наступательной безопасности», — сказал The Daily Swig Ласло Эрдоди, ведущий автор статьи и постдокторант кафедры информатики Университета Осло.

«Мы решили попробовать машинное обучение для тестирования на проникновение и обнаружили, что RL (обучение с подкреплением) является очень многообещающим подходом. Как и ожидалось, он продемонстрировал, что уязвимости к SQL-инъекциям можно легко использовать с RL ».

Следите за последними новостями в области безопасности SQL-инъекций

SQL-инъекции (SQLi) — это уязвимость веб-безопасности, которая позволяет злоумышленнику вмешиваться в запросы, которые приложение делает к своей базе данных. Злоумышленники используют эксплойты SQLi для просмотра данных, которые они обычно не могут получить, или для внесения изменений в базу данных.

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

Глубокое Q-обучение показало первые перспективы в улучшении исследований SQLi.

Исследователи начали с отправки множества случайных запросов и анализа результатов.Постепенно они разработали модель, в которой они могли провести успешную атаку в среднем за 4-5 запросов.

Существующие автоматизированные инструменты SQLi полагаются на статические, предопределенные правила, говорит Эрдоди, что может ограничить их применение. «Большим преимуществом использования RL для таких задач является то, что логика атаки не определена и не статична.

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

« Некоторые ограничения »

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

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

«Текущее решение имеет некоторые ограничения с точки зрения сделанных нами предположений», — признал Эрдоди. «С другой стороны, эти допущения были введены только для уменьшения сложности проблемы для первого подхода.

«Рассматривая все больше и больше возможностей для агента, он увеличивает пространство действий и пространство состояний».

«Многообещающие результаты»

Исследователи протестировали два варианта обучения с подкреплением для решения этой задачи.

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

Второй метод — глубокое Q-обучение, сочетающее Q-обучение с глубокими нейронными сетями. Глубокое Q-обучение может решать задачи с более сложным набором состояний и действий.

В последние годы ученые использовали глубокое Q-обучение для создания систем искусственного интеллекта, которые могут решать сложные задачи, такие как освоение сложных игр, таких как Go и StarCraft 2.

Узнайте больше о последних новостях в области безопасности искусственного интеллекта

Модель глубокого Q-обучения достигла удовлетворительного уровня производительности при решении задачи SQLi намного быстрее, чем классический агент Q-Learning. Окончательная модель также была намного меньше, достигая размера не более нескольких сотен килобайт.

«Глубокое обучение Q показало очень многообещающие результаты», — говорит Эрдоди. «Этот подход может быть использован в будущем для более реалистичного моделирования, возможно, без ограничивающих предположений.

«В настоящее время мы работаем над этим моделированием, цель которого — использовать RL в тестировании на проникновение в реальном слове.

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

Другая работа в этой области включает модель машинного обучения, разработанную фирмой по кибербезопасности NCC Group.

NCC использует алгоритм машинного обучения машины опорных векторов (SVM) для обнаружения уязвимостей SQLi на веб-страницах на основе ответов, полученных от серверов.

Эрдоди и его соавторы представили свой доклад на рассмотрение 13-й Международной конференции по кибер-конфликтам (Cycon 2021). Их работа является частью более широкой исследовательской программы Университета Осло, которая направлена ​​на разработку интеллектуальных агентов как для автоматического тестирования на проникновение, так и для автоматического реагирования.

«Такой взгляд на будущее кибербезопасности можно назвать« кибервойной алгоритмов », в которой и кибератаки, и защита становятся автоматизированными», — говорит Эрдоди.

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

РЕКОМЕНДУЕМЫЕ «Бэкдоры без триггеров» могут заражать модели машинного обучения, не оставляя следов — исследование

Основы

SQL — Практическое руководство по SQL для начинающих Анализирование совместного использования велосипедов

В этом руководстве мы будем работать с набором данных из службы проката велосипедов Hubway, который включает данные о более чем 1,5 миллионах поездок, совершенных с помощью этой службы.

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

Если вы хотите продолжить, вы можете загрузить файл hubway.db здесь (130 МБ).

Основы SQL: реляционные базы данных

Реляционная база данных — это база данных, которая хранит связанную информацию в нескольких таблицах и позволяет запрашивать информацию в нескольких таблицах одновременно.

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

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

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

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

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

Наш набор данных

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

• id — Уникальное целое число, которое служит ссылкой для каждой поездки
• duration — Продолжительность поездки в секундах
• start_date — Дата и время начала поездки
• start_station — Целое число, которое соответствует столбцу id в таблице station для станции, с которой началась поездка
• end_date — Дата и время окончания поездки
• end_station — ‘id’ станции, на которой завершилась поездка
• bike_number — Уникальный идентификатор Hubway для велосипеда, использованного в поездке
• sub_type — Тип подписки пользователя. «Зарегистрированные» для пользователей с членством, «Обычные» для пользователей без членства
• zip_code — Почтовый индекс пользователя (доступен только для зарегистрированных пользователей)
• Birth_date — Год рождения пользователя (доступно только для зарегистрированных участников)
• пол — пол пользователя (доступно только для зарегистрированных пользователей)

Наш анализ

С этой информацией и командами SQL, которые мы вскоре узнаем, вот несколько вопросов, на которые мы попытаемся ответить в ходе этого поста:

• Какова была самая длинная поездка?
• Сколько поездок совершили «зарегистрированные» пользователи?
• Какая была средняя продолжительность поездки?
• Бывают ли длительные поездки зарегистрированные или случайные пользователи?
• Какой велосипед использовался для большинства поездок?
• Какова средняя продолжительность поездок пользователей старше 30 лет?

Для ответа на эти вопросы мы будем использовать команды SQL:

• ВЫБРАТЬ
• ГДЕ
• ПРЕДЕЛ
• ЗАКАЗАТЬ В №
• ГРУППА ПО
• И
• ИЛИ
• МИН.
• МАКС
• СРЕДНЯЯ
• СУММ
• СЧЕТ

Установка и настройка

В этом руководстве мы будем использовать систему баз данных под названием SQLite3.SQLite входит в состав Python начиная с версии 2.5, поэтому, если у вас установлен Python, у вас почти наверняка будет и SQLite. Python и библиотеку SQLite3 можно легко установить и настроить с помощью Anaconda, если у вас их еще нет.

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

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

  ~ $ sqlite hubway.db SQLite версии 3.14.0 2016-07-26 15: 17: 14 Введите ".help" для использования hints.sqlite>  

Отсюда мы можем просто ввести запрос, который хотим запустить, и мы увидим данные, возвращенные в окне нашего терминала.

Альтернативой использованию терминала является подключение к базе данных SQLite через Python.Это позволит нам использовать блокнот Jupyter, чтобы мы могли видеть результаты наших запросов в аккуратно отформатированной таблице.

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

  импорт sqlite3
импортировать панд как pd
db = sqlite3.connect ('hubway.db')
def run_query (запрос):
    вернуть pd.read_sql_query (запрос, db)  

Конечно, нам не обязательно использовать Python с SQL. Если вы уже являетесь программистом R, наш курс «Основы SQL для пользователей R» будет отличным местом для начала.

ВЫБРАТЬ

Первая команда, с которой мы будем работать, — это SELECT . SELECT будет основой почти каждого написанного нами запроса — он сообщает базе данных, какие столбцы мы хотим видеть. Мы можем указать столбцы по имени (разделенные запятыми) или использовать подстановочный знак * , чтобы вернуть каждый столбец в таблице.

В дополнение к столбцам, которые мы хотим получить, мы также должны указать базе данных, из какой таблицы их получить. Для этого мы используем ключевое слово FROM , за которым следует имя таблицы.Например, если бы мы хотели видеть start_date и bike_number для каждой поездки в таблице trips , мы могли бы использовать следующий запрос:

  ВЫБРАТЬ start_date, bike_number ИЗ поездок;  

В этом примере мы начали с команды SELECT , чтобы база данных знала, что мы хотим, чтобы она нашла нам некоторые данные. Затем мы сообщили базе данных, что нас интересуют столбцы start_date и bike_number .Наконец, мы использовали FROM , чтобы сообщить базе данных, что столбцы, которые мы хотим видеть, являются частью таблицы trips .

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

LIMIT

Следующая команда, которую нам нужно знать, прежде чем мы начнем выполнять запросы в нашей базе данных Hubway, — это LIMIT . LIMIT просто сообщает базе данных, сколько строк вы хотите вернуть.

Запрос SELECT , который мы рассмотрели в предыдущем разделе, будет возвращать запрошенную информацию для каждой строки в таблице trips , но иногда это может означать большой объем данных. Мы можем не захотеть всего этого. Если бы вместо этого мы хотели видеть start_date и bike_number для первых пяти поездок в базе данных, мы могли бы добавить LIMIT к нашему запросу следующим образом:

  ВЫБРАТЬ start_date, bike_number ИЗ поездок LIMIT 5;  

Мы просто добавили команду LIMIT , а затем число, представляющее количество строк, которые мы хотим вернуть.В этом случае мы использовали 5, но вы можете заменить его любым числом, чтобы получить соответствующий объем данных для проекта, над которым вы работаете.

Мы будем часто использовать LIMIT в наших запросах к базе данных Hubway в этом руководстве — таблица trips содержит более 1,5 миллиона строк данных, и нам определенно не нужно отображать их все!

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

  query = 'ВЫБРАТЬ * ИЗ ОТКЛЮЧЕНИЯ ОГРАНИЧЕНИЯ 5;'
run_query (запрос)  

	id	продолжительность	start_date	start_station	end_date	конечная станция	номер велосипеда	подтип	почтовый индекс	дата рождения	пол
0	1	9	28.07.2011 10:12:00	23	28.07.2011 10:12:00	23	B00468	Зарегистрировано	‘97217	1976 г.0	Мужской
1	2	220	28.07.2011 10:21:00	23	28.07.2011 10:25:00	23	B00554	Зарегистрировано	‘02215	1966,0	Мужской
2	3	56	28. 07.2011 10:33:00	23	28.07.2011 10:34:00	23	B00456	Зарегистрировано	‘02108	1943 г.0	Мужской
3	4	64	28.07.2011 10:35:00	23	28.07.2011 10:36:00	23	B00554	Зарегистрировано	‘02116	1981,0	Женский
4	5	12	28.07.2011 10:37:00	23	28.07.2011 10:37:00	23	B00554	Зарегистрировано	‘97214	1983 г.0	Женский

Этот запрос использует * в качестве подстановочного знака вместо указания возвращаемых столбцов. Это означает, что команда SELECT дала нам каждый столбец в таблице отключения . Мы также использовали функцию LIMIT , чтобы ограничить вывод первыми пятью строками таблицы.

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

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

  query = 'ВЫБЕРИТЕ продолжительность, начальная_дата ИЗ ПРЕДЕЛ 5 отключений'
run_query (запрос)  

	продолжительность	start_date
0	9	28.07.2011 10:12:00
1	220	28. 07.2011 10:21:00
2	56	28.07.2011 10:33:00
3	64	28.07.2011 10:35:00
4	12	28.07.2011 10:37:00

ЗАКАЗАТЬ В

Последняя команда, которую нам нужно знать, прежде чем мы сможем ответить на первый из наших вопросов, — это ORDER BY .Эта команда позволяет нам отсортировать базу данных по заданному столбцу.

Чтобы использовать его, мы просто указываем имя столбца, по которому хотим выполнить сортировку. По умолчанию ORDER BY сортируется в порядке возрастания. Если мы хотим указать, в каком порядке база данных должна быть отсортирована, мы можем добавить ключевое слово ASC для возрастания или DESC для убывания.

Например, если мы хотим отсортировать таблицу поездок от самой короткой продолжительности к самой длинной, мы могли бы добавить в наш запрос следующую строку:

  ЗАКАЗАТЬ ПО продолжительности ASC  

С помощью команд SELECT , LIMIT и ORDER BY в нашем репертуаре мы можем теперь попытаться ответить на наш первый вопрос: Какова была продолжительность самой продолжительной поездки?

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

Сначала нам нужно извлечь информацию из столбца длительности таблицы поездок . Затем, чтобы определить, какая поездка самая длинная, мы можем отсортировать столбец длительность в порядке убывания. Вот как мы можем проработать это, чтобы создать запрос, который получит информацию, которую мы ищем:

• Используйте SELECT для получения продолжительности столбца FROM отключает таблица
• Используйте ORDER BY для сортировки столбца продолжительности и используйте ключевое слово DESC , чтобы указать, что вы хотите отсортировать в порядке убывания
• Используйте LIMIT , чтобы ограничить вывод до 1 строки

Использование этих команд таким образом вернет единственную строку с самой длинной продолжительностью, которая даст нам ответ на наш вопрос.

Еще одно замечание: по мере того, как ваши запросы добавляют больше команд и усложняются, вам может быть легче читать, если вы разделите их на несколько строк. Это, как и использование заглавных букв, зависит от личных предпочтений. Это не влияет на выполнение кода (система просто считывает код с начала до точки с запятой), но может сделать ваши запросы более понятными и более понятными. В Python мы можем разделить строку на несколько строк, используя тройные кавычки.

Давайте продолжим и запустим этот запрос и выясним, как долго длилась самая длинная поездка.

  запрос = '' '
ВЫБЕРИТЕ продолжительность ИЗ поездок
ЗАКАЗАТЬ ПО длительности DESC
LIMIT 1;
'' '
run_query (запрос)  

Теперь мы знаем, что самая длинная поездка длилась 9999 секунд, или чуть более 166 минут. Однако при максимальном значении 9999 мы не знаем, действительно ли это длина самой длинной поездки или база данных была настроена только для четырехзначного числа.

Если это правда, что база данных сокращает особенно длинные поездки, то мы можем ожидать увидеть много поездок на 9999 секундах, где они достигают предела.Давайте попробуем выполнить тот же запрос, что и раньше, но отрегулируем LIMIT , чтобы вернуть 10 самых высоких значений длительности, чтобы проверить, так ли это:

  запрос = '' '
ВЫБЕРИТЕ продолжительность из поездок
ЗАКАЗАТЬ ПО длительности DESC
ПРЕДЕЛ 10
'' '
run_query (запрос)  

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

Hubway взимает дополнительную плату за поездки продолжительностью более 30 минут (кто-то, кто держит велосипед в течение 9999 секунд, должен будет заплатить дополнительные 25 долларов США), поэтому вполне вероятно, что они решили, что 4 цифры будут достаточными для отслеживания большинства поездок.

ГДЕ

Предыдущие команды отлично подходят для извлечения отсортированной информации для определенных столбцов, но что, если есть определенное подмножество данных, которые мы хотим просмотреть? Вот где появляется WHERE . Команда WHERE позволяет нам использовать логический оператор, чтобы указать, какие строки должны быть возвращены.Например, вы можете использовать следующую команду, чтобы отображать информацию о каждой поездке на велосипеде B00400 :

  ГДЕ bike_number = "B00400"  

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

Давайте напишем запрос, который использует WHERE для возврата каждого столбца в таблице поездок для каждой строки с продолжительностью дольше 9990 секунд:

  запрос = '' '
ВЫБРАТЬ * ИЗ поездок
ГДЕ длительность> 9990;
'' '
run_query (запрос)  

	id	продолжительность	start_date	start_station	end_date	конечная станция	номер велосипеда	подтип	почтовый индекс	дата рождения	пол
0	4768	9994	2011-08-03 17:16:00	22	2011-08-03 20:03:00	24	B00002	Повседневный
1	8448	9991	2011-08-06 13:02:00	52	2011-08-06 15:48:00	24	B00174	Повседневный
2	11341	9998	2011-08-09 10:42:00	40	2011-08-09 13:29:00	42	B00513	Повседневный
3	24455	9995	20. 08.2011 12:20:00	52	20.08.2011 15:07:00	17	B00552	Повседневный
4	55771	9994	14.09.2011 15:44:00	40	14.09.2011 18:30:00	40	B00139	Повседневный
5	81191	9993	2011-10-03 11:30:00	22	2011-10-03 14:16:00	36	B00474	Повседневный
6	89335	9997	2011-10-09 02:30:00	60	2011-10-09 05:17:00	45	B00047	Повседневный
7	124500	9992	2011-11-09 09:08:00	22	2011-11-09 11:55:00	40	B00387	Повседневный
8	133967	9996	2011-11-19 13:48:00	4	2011-11-19 16:35:00	58	B00238	Повседневный
9	147451	9996	23. 03.2012 14:48:00	35	23.03.2012 17:35:00	33	B00550	Повседневный
10	315737	9995	2012-07-03 18:28:00	12	2012-07-03 21:15:00	12	B00250	Зарегистрировано	‘02120	1964	Мужской
11	319597	9994	05.07.2012 11:49:00	52	05.07.2012 14:35:00	55	B00237	Повседневный
12	416523	9998	2012-08-15 12:11:00	54	15.08.2012 14:58:00	80	B00188	Повседневный
13	541247	9999	26-09-2012 18:34:00	54	26.09.2012 21:21:00	54	T01078	Повседневный

Как мы видим, этот запрос вернул 14 различных поездок, каждая длительностью 9990 секунд или более. Что выделяется в этом запросе, так это то, что все результаты, кроме одного, имеют sub_type из "Случайный" . Возможно, это показатель того, что «Зарегистрированных» пользователя больше осведомлены о дополнительных сборах за дальние поездки. Возможно, Hubway сможет лучше донести свою структуру ценообразования до обычных пользователей, чтобы помочь им избежать дополнительных расходов.

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

Возвращаясь к WHERE , мы также можем объединить несколько логических тестов в нашем предложении WHERE , используя AND или OR . Если, например, в нашем предыдущем запросе мы хотели вернуть только поездки с продолжительностью за 9990 секунд, которые также имели подтип , равный Зарегистрированный, мы могли бы использовать И , чтобы указать оба условия.

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

Теперь давайте запустим этот запрос. Мы уже знаем, что он должен возвращать только один результат, поэтому будет легко убедиться, что мы все правильно сделали:

  запрос = '' '
ВЫБРАТЬ * ИЗ поездок
ГДЕ (продолжительность> = 9990) И (sub_type = "Зарегистрировано")
ORDER BY продолжительности DESC;
'' '
run_query (запрос)  

	id	продолжительность	start_date	start_station	end_date	конечная станция	номер велосипеда	подтип	почтовый индекс	дата рождения	пол
0	315737	9995	2012-07-03 18:28:00	12	2012-07-03 21:15:00	12	B00250	Зарегистрировано	‘02120	1964 г. 0	Мужской

Следующий вопрос, который мы задали в начале поста, — «Сколько поездок совершили« зарегистрированные »пользователи?» Чтобы ответить на него, мы могли бы выполнить тот же запрос, что и выше, и изменить выражение WHERE , чтобы вернуть все строки, где sub_type равен 'Registered' , а затем подсчитать их.

Однако на самом деле в SQL есть встроенная команда для этого подсчета: COUNT .

COUNT позволяет перенести вычисления в базу данных и избавить нас от необходимости писать дополнительные скрипты для подсчета результатов. Чтобы использовать его, мы просто включаем COUNT (column_name) вместо (или в дополнение к) столбцов, которые вы хотите SELECT , например:

  ВЫБРАТЬ СЧЕТЧИК (id)
ИЗ поездок  

В этом случае не имеет значения, какой столбец мы выберем для подсчета, потому что каждый столбец должен содержать данные для каждой строки в нашем запросе. Но иногда в запросе могут отсутствовать (или «нулевые») значения для некоторых строк. Если мы не уверены, содержит ли столбец нулевые значения, мы можем запустить наш COUNT для столбца id — столбец id никогда не будет нулевым, поэтому мы можем быть уверены, что наш счетчик ничего не пропустил.

Мы также можем использовать COUNT (1) или COUNT (*) для подсчета каждой строки в нашем запросе. Стоит отметить, что иногда нам может потребоваться запустить COUNT для столбца с нулевыми значениями.Например, нам может потребоваться узнать, сколько строк в нашей базе данных имеют отсутствующие значения для столбца.

Давайте взглянем на запрос, чтобы ответить на наш вопрос. Мы можем использовать SELECT COUNT (*) для подсчета общего количества возвращенных строк и WHERE sub_type = "Registered" , чтобы убедиться, что мы подсчитываем только поездки, совершенные зарегистрированными пользователями.

  запрос = '' '
ВЫБРАТЬ КОЛИЧЕСТВО (*) ИЗ поездок
WHERE sub_type = "Зарегистрировано";
'' '
run_query (запрос)  

Этот запрос сработал и вернул ответ на наш вопрос.Но заголовок столбца не особо описательный. Если бы кто-то другой взглянул на эту таблицу, он не смог бы понять, что это значит.

Если мы хотим сделать наши результаты более удобочитаемыми, мы можем использовать AS , чтобы дать нашему выводу псевдоним (или псевдоним). Давайте повторно запустим предыдущий запрос, но дадим нашему заголовку столбца псевдоним Всего поездок по зарегистрированным пользователям :

  запрос = '' '
ВЫБЕРИТЕ СЧЕТЧИК (*) КАК "Общее количество поездок зарегистрированных пользователей"
ИЗ поездок
WHERE sub_type = "Зарегистрировано";
'' '
run_query (запрос)  

Агрегатные функции

COUNT — не единственный математический трюк, который SQL использует в своих рукавах. Мы также можем использовать SUM , AVG , MIN и MAX для возврата суммы, среднего, минимального и максимального значения столбца соответственно. Они, наряду с COUNT , известны как агрегатные функции.

Итак, чтобы ответить на наш третий вопрос, «Какова была средняя продолжительность поездки?» , мы можем использовать функцию AVG в столбце длительности (и, опять же, использовать AS , чтобы дать нашему выходному столбцу более информативное имя):

  запрос = '' '
ВЫБЕРИТЕ СРЕДНЮЮ (продолжительность) КАК "Средняя продолжительность"
ОТ поездок;
'' '
run_query (запрос)  

Получается, что средняя продолжительность поездки составляет 912 секунд, то есть примерно 15 минут. В этом есть смысл, поскольку мы знаем, что Hubway взимает дополнительную плату за поездки продолжительностью более 30 минут. Услуга предназначена для любителей коротких поездок в одну сторону.

Что насчет нашего следующего вопроса: , зарегистрированные или случайные пользователи совершают более длительные поездки? Мы уже знаем один способ ответить на этот вопрос — мы могли бы запустить два запроса SELECT AVG (duration) FROM для отключения с предложениями WHERE , которые ограничивают один до «зарегистрированных» и один до «случайных» пользователей.

Но давайте сделаем по-другому. SQL также включает способ ответить на этот вопрос в одном запросе с помощью команды GROUP BY .

ГРУППА BY

GROUP BY разделяет строки на группы на основе содержимого определенного столбца и позволяет нам выполнять агрегатные функции для каждой группы.

Чтобы лучше понять, как это работает, давайте взглянем на столбец пол . Каждая строка может иметь одно из трех возможных значений в столбце пол , «Мужской» , «Женский» или Нулевой (отсутствует; у нас нет данных пол для случайных пользователей).

Когда мы используем GROUP BY , база данных разделяет каждую из строк в другую группу на основе значения в столбце пол , почти так же, как мы можем разделить колоду карт на разные масти. . Мы можем представить себе две кучки, одну из самцов, одну из самок.

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

Давайте подробно рассмотрим, как написать запрос, чтобы ответить на наш вопрос о том, совершают ли более длительные поездки зарегистрированные или случайные пользователи.

• Как и в случае с каждым из наших запросов, мы начнем с SELECT , чтобы сообщить базе данных, какую информацию мы хотим видеть. В этом случае нам нужны sub_type и AVG (продолжительность) .
• Мы также включим GROUP BY sub_type , чтобы разделить наши данные по типу подписки и отдельно вычислить средние значения зарегистрированных и случайных пользователей.

Вот как выглядит код, если собрать все вместе:

  запрос = '' '
SELECT sub_type, AVG (duration) AS "Средняя продолжительность"
ИЗ поездок
GROUP BY sub_type;
'' '
run_query (запрос)  

Вот это большая разница! В среднем зарегистрированные пользователи совершают поездки продолжительностью около 11 минут, тогда как обычные пользователи тратят почти 25 минут на поездку. Зарегистрированные пользователи, вероятно, будут совершать более короткие и частые поездки, возможно, по дороге на работу. С другой стороны, обычные пользователи тратят примерно вдвое больше времени на поездку.

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

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

  запрос = '' '
ВЫБЕРИТЕ bike_number как "Номер велосипеда", COUNT (*) как "Количество поездок"
ИЗ поездок
ГРУППА ПО номеру велосипеда
ЗАКАЗАТЬ ПО КОЛИЧЕСТВУ (*) УДАЛ. 
LIMIT 1;
'' '
run_query (запрос)  

Как видно из выходных данных, наибольшее количество поездок ездил на велосипеде B00490 .Давайте разберемся, как мы туда попали:

• Первая строка — это предложение SELECT , чтобы сообщить базе данных, что мы хотим видеть столбец bike_number и счетчик каждой строки. Он также использует AS , чтобы указать базе данных отображать каждый столбец с более удобным именем.
• Во второй строке используется ИЗ , чтобы указать, что данные, которые мы ищем, находятся в таблице поездок .
• В третьей строке все становится немного сложнее.Мы используем GROUP BY , чтобы сообщить функции COUNT в строке 1, чтобы подсчитывать каждое значение для bike_number отдельно.
• В четвертой строке у нас есть предложение ORDER BY , чтобы отсортировать таблицу в порядке убывания и убедиться, что наш наиболее часто используемый велосипед находится наверху.
• Наконец, мы используем LIMIT , чтобы ограничить вывод первой строкой, которая, как мы знаем, будет велосипедом, который использовался в наибольшем количестве поездок, из-за того, как мы отсортировали данные в четвертой строке.

Арифметические операторы

Наш последний вопрос немного сложнее остальных. Мы хотим знать средней продолжительности поездок зарегистрированных пользователей старше 30 лет .

Мы могли бы просто вычислить год, в котором 30-летние родились в нашей голове, а затем подключить его, но более элегантное решение — использовать арифметические операции непосредственно в нашем запросе. SQL позволяет нам использовать + , - , * и / для выполнения арифметической операции сразу над всем столбцом.

  запрос = '' '
ВЫБРАТЬ СРЕДНЕЕ (длительность) ИЗ поездок
ГДЕ (2017 - дата рождения)> 30;
'' '
run_query (запрос)  

ПРИСОЕДИНЯЙТЕСЬ

До сих пор мы рассматривали запросы, которые извлекают данные только из таблицы , отключает . Однако одна из причин, по которой SQL является настолько мощным, заключается в том, что он позволяет нам извлекать данные из нескольких таблиц в одном запросе.

Наша база данных по прокату велосипедов содержит вторую таблицу, станций . Таблица станций содержит информацию о каждой станции в сети Hubway и включает столбец id , на который ссылается таблица поездок .

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

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

  ВЫБРАТЬ номер_заказа, имя
ОТ заказов;  

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

• В какой таблице находится столбец order_number ?
• В какой таблице находится столбец имя ?
• Как информация в таблице orders связана с информацией в таблице customers ?

Чтобы ответить на первые два из этих вопросов, мы можем включить имена таблиц для каждого столбца в нашу команду SELECT . Мы делаем это, просто записывая имя таблицы и имя столбца, разделенные . . Например, вместо SELECT order_number, name мы должны написать SELECT orders.order_number, customers.name . Добавление здесь имен таблиц помогает базе данных найти нужные столбцы, сообщая ей, в какой таблице искать каждый.

Чтобы сообщить базе данных, как связаны таблицы orders и customers , мы используем JOIN и ON . JOIN указывает, какие таблицы должны быть связаны, а ON указывает, какие столбцы в каждой таблице связаны.

Мы собираемся использовать внутреннее соединение, что означает, что строки будут возвращаться только в том случае, если есть совпадения в столбцах, указанных в ON . В этом примере мы захотим использовать JOIN для той таблицы, которую мы не включили в команду FROM . Таким образом, мы можем использовать FROM заказов INNER JOIN клиентов или FROM клиентов INNER JOIN orders .

Как мы обсуждали ранее, эти таблицы связаны по столбцу customer_id в каждой таблице. Следовательно, мы захотим использовать ON , чтобы сообщить базе данных, что эти два столбца относятся к одному и тому же объекту, например:

  ON orders.customer_ID = customers.customer_id  

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

  ВЫБРАТЬ заказы.order_number, customers.name
ИЗ заказов
INNER JOIN клиенты
ON orders.customer_id = customers.customer_id  

Этот запрос вернет порядковый номер каждого заказа в базе данных вместе с именем клиента, которое связано с каждым заказом.

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

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

  запрос = '' '
ВЫБРАТЬ * ИЗ станций
LIMIT 5;
'' '
run_query (запрос)  

	id	станция	муниципалитет	шир.	lng
0	3	Колледжи Фенуэй	Бостон	42.340021	-71.100812
1	4	Tremont St., Berkeley St.,	Бостон	42.345392	-71.069616
2	5	Северо-восточная / Северная парковка	Бостон	42,341814	-71.0
3	6	Кембридж-стрит на Джой-стрит	Бостон	42,361284999999995	-71.06514
4	7	Причал вентилятора	Бостон	42,35 3412	-71. 044624

• id — Уникальный идентификатор для каждой станции (соответствует столбцам start_station и end_station в таблице поездок )
• станция — Название станции
• муниципалитет — муниципалитет, в котором находится станция (Бостон, Бруклин, Кембридж или Сомервилль)
• lat — Широта станции
• lng — Долгота станции
• Какие станции чаще всего используются для поездок туда и обратно?
• Сколько поездок начинается и заканчивается в разных муниципалитетах?

Как и раньше, мы попытаемся ответить на некоторые вопросы в данных, начиная с , какая станция является наиболее частой отправной точкой? Давайте поработаем пошагово:

• Сначала мы хотим использовать SELECT для возврата столбца station из таблицы station и COUNT количества строк.
• Затем мы указываем таблицы, к которым мы хотим JOIN , и говорим базе данных подключить их ON , столбец start_station в таблице trips и столбец id в таблице station .
• Затем мы переходим к сути нашего запроса — мы GROUP BY столбец station в таблице station , чтобы наш COUNT подсчитывал количество поездок для каждой станции отдельно
• Наконец, мы можем ORDER BY наши COUNT и LIMIT выводить на управляемое количество результатов

  запрос = '' '
ВЫБЕРИТЕ станции.станция AS "Станция", COUNT (*) AS "Count"
ИЗ рейсов INNER JOIN станции
ВКЛ. Trips.start_station = station.idGROUP BY station.station ORDER BY COUNT (*) DESC
LIMIT 5;
'' '
run_query (запрос)  

	Станция	Счетчик
0	Южный вокзал — 700 Атлантик авеню,	56123
1	Публичная библиотека Бостона — 700 Boylston St.	41994
2	Charles Circle — Charles St.на Кембридж-стрит	35984
3	Beacon St / Mass Ave	35275
4	MIT на Mass Ave / Amherst St	33644

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

Следующий вопрос, который мы рассмотрим, это , какие станции наиболее часто используются для поездок туда и обратно? Мы можем использовать тот же запрос, что и раньше. Мы будем ВЫБРАТЬ те же выходные столбцы и СОЕДИНЯТЬ таблицы таким же образом, но на этот раз мы добавим предложение WHERE , чтобы ограничить наш COUNT поездками, где start_station совпадает с конечная станция .

  query = '' 'ВЫБРАТЬ станции.станция КАК "Станция", СЧЁТ (*) КАК "Счетчик"
ИЗ рейсов INNER JOIN станции
ПО поездкам.start_station = station.id
ГДЕ trips.start_station = trips.end_station
ГРУППА ПО станциям. Станции
ЗАКАЗАТЬ ПО КОЛИЧЕСТВУ (*) УДАЛ.
LIMIT 5;
'' '
run_query (запрос)  

Как мы видим, количество этих станций такое же, как и в предыдущем вопросе, но их количество намного меньше. Самые загруженные станции по-прежнему остаются самыми загруженными, но в целом более низкие цифры говорят о том, что люди обычно используют велосипеды Hubway, чтобы добраться из точки A в точку B, а не ездят на велосипеде какое-то время, прежде чем вернуться туда, откуда они начали.

Здесь есть одно существенное отличие — Esplande, которая не была одной из самых загруженных станций по нашему первому запросу, кажется, самая загруженная для поездок туда и обратно. Почему? Что ж, картинка стоит тысячи слов. Это определенно похоже на хорошее место для велосипедной прогулки:

Переходим к следующему вопросу: сколько поездок начинается и заканчивается в разных муниципалитетах? Этот вопрос продвигает дальше. Мы хотим знать, сколько поездок начинается и заканчивается в другом муниципалитете .Чтобы достичь этого, нам нужно JOIN , чтобы дважды подключала таблицу к таблице станций . После ON столбец start_station , а затем ON столбец end_station .

Для этого мы должны создать псевдоним для таблицы station , чтобы мы могли различать данные, относящиеся к start_station , и данные, которые относятся к end_station . Мы можем сделать это точно так же, как мы создавали псевдонимы для отдельных столбцов, чтобы они отображались с более интуитивно понятным именем, используя AS .

Например, мы можем использовать следующий код для ПРИСОЕДИНЯЙТЕСЬ к таблице станций к таблице поездок , используя псевдоним «начало». Затем мы можем объединить «начало» с именами столбцов, используя . для ссылки на данные, которые поступают из этого конкретного JOIN (вместо второго JOIN мы будем делать ON в столбце end_station ):

  ВНУТРЕННЕЕ СОЕДИНЕНИЕ станций КАК запускается на trips.start_station = start.id  

Вот как будет выглядеть окончательный запрос, когда мы его запустим. Обратите внимание, что мы использовали <> для обозначения «не равно», но ! = также подойдет.

  запрос =
'' '
ВЫБЕРИТЕ COUNT (trips.id) КАК "Count"
ИЗ поездок ВНУТРЕННИЕ СОЕДИНЯЙТЕ станции КАК старт
ВКЛ. Trips.start_station = start.id
INNER JOIN станции как конец
ON trips.end_station = end.id
ГДЕ start.municipality <> end.municipality;
'' '
run_query (запрос)  

Это показывает, что около 300000 из 1.5 миллионов поездок (или 20%) закончились в другом муниципалитете, чем они начали, — еще одно свидетельство того, что люди в основном используют велосипеды Hubway для относительно коротких поездок, а не для длительных поездок между городами.

Если вы зашли так далеко, поздравляем! Вы начали осваивать основы SQL. Мы рассмотрели ряд важных команд, SELECT , LIMIT , WHERE , ORDER BY , GROUP BY и JOIN , а также агрегатные и арифметические функции. Это даст вам прочную основу для дальнейшего развития SQL.

Вы освоили основы SQL. Что теперь?

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

• За сколько поездок потребовалась дополнительная плата (продолжительностью более 30 минут)?
• Какой велосипед использовался дольше всего?
• Были ли у зарегистрированных или случайных пользователей больше поездок туда и обратно?
• У какого муниципалитета была самая большая средняя продолжительность жизни?

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

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

Введение в SQL

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

Таким образом, абсолютно необходимо, чтобы понимание этой структурированной модели хранения и поиска данных с нуля имело первостепенное значение. Однако новичок, естественно, чувствует себя потерянным в море информации, доступной в диком мире. Эта серия, «Введение в SQL», приходит на помощь, поскольку начинается с самой основы SQL — самой ткани — а затем, начиная оттуда, к более широкой картине.

Почему вы должны использовать SQL в 2020 году

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

Поймите, что SQL никуда не денется. Во всяком случае, это только стало горячим пирогом с дальнейшим толчком в конкуренции со стороны некоторых стратегических драйверов, таких как Microsoft, которые теперь сделали SQL доступным и для Linux. Различные облачные предложения, такие как Microsoft Azure и Amazon Web Services — два крупнейших игрока в этой области — имеют очень специализированный подход к модели реляционной базы данных и, следовательно, к SQL. И это только начало новой эры.

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

Почему важен SQL? Какую проблему это решает?

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

Поэтому в этой книге мы начнем с введения в сам SQL, а затем разберемся с важными функциями SQL Server.Главы проведут вас через демонстрацию внутренней работы SQL, начиная со стандартов SQL, эволюции, истории (это важно, чтобы вы знали, как он вырос и стал зверем, каким он является сегодня, и чтобы вы могли использовать его потенциал. powers) и переходит к созданию таблиц, пониманию и определению отношений, написанию команд Transact ‑ SQL и так далее.

Вы также поймете, что SQL — это язык программирования специального назначения; специального назначения, например, он отличается от языков программирования общего назначения, таких как C, C ++, Java / JavaScript и т. д., что означает, что он имеет очень конкретную цель: манипулирование наборами данных. И эта манипуляция происходит с использованием так называемого реляционного исчисления .

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

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

Какие еще есть инструменты? Почему SQL лучше?

Есть разные способы хранения данных. Один из способов хранения — установить определенную структуру на основе блоков, которые вы будете использовать для хранения данных, и хранить данные в этой структуре.Это модель хранения с предопределенной схемой . SQL лучше всего подходит для этой модели хранения данных.

Доступно несколько инструментов для управления, сравнения, администрирования и разработки баз данных SQL. Разные инструменты созданы для разных целей и имеют свои плюсы и минусы. Однако основной структурой является SQL.

SQL существует уже давно: первый продукт SQL, доступный для публичного использования, был запущен в 1979 году — Oracle версии 2 — и Oracle остается одной из ведущих систем баз данных сегодня.И основные концепции с тех пор остались прежними, с большинством операций (и команд) SQL с участием четырех основных глаголов: Select, Insert, Update и Delete. Кроме того, SQL обычно не зависит от пробелов, что означает, что добавление пробелов внутри или между предложениями не имеет значения. Большинство SQL-запросов стандартизированы, чтобы выглядеть как вопрос, который вы задаете объекту базы данных, на который указанный объект базы данных знает, как ответить. SQL использует интерпретатор команд для анализа SQL-запроса. А поскольку SQL в сочетании с интерпретатором является настолько мощным, что его внедрили во многие продукты для баз данных.

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

Как SQL может помочь разработчикам?

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

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

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

Консультации для разработчиков и администраторов SQL

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

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

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

Моделирование данных

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

Тысячи SQL-запросов

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

Медленно выполняющиеся запросы

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

Целостность данных

Это также важная часть моделирования данных. Данные в базе данных SQL хранятся с ограничениями.Эти ограничения являются неотъемлемой частью архитектуры. Если ваша база данных не имеет продуманных ограничений, ваши данные будут беспорядочными. Как правило, в проектах, рассчитанных на годы, обычно получаются записи, которые не очищаются, когда они больше не требуются.

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

Начните работу с SQL с этого курса. Мы понимаем системы, понимаем отрасль и понимаем — благодаря нашему многолетнему опыту — различные точки отказа. Этот курс охватывает ключевые темы SQL, такие как агрегатные функции, ограничения, объединения, подзапросы и т. Д., Которые будут неоценимы при работе с базами данных. Курс начинается с самых основ — например, «что такое CRUD» — и не предполагает знания баз данных со стороны читателя. Курс SQL для начинающих.

Основные мифы об SQL

Излюбленные мифы о SQL в мире — это мифы о сравнении SQL и NoSQL. Часто говорят, что NoSQL заменит SQL. Это неправда. Фактически, NoSQL возник в шестидесятых годах — даже до того, как появился SQL. SQL и NoSQL — два дополнительных решения. Один лучше подходит, чем другой, в зависимости от системы, в которой они будут использоваться.

Также распространено мнение, что SQL и NoSQL имеют четкое различие.Дело в том, что грань, отделяющая NoSQL от SQL, все больше и больше стирается по мере развития двух систем. Возникает NewSQL, гибрид между ними двумя. И факт остается фактом: для работы с этими новыми системами вам необходимо знать SQL.

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

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

Резюме

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

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

Также SQL повсеместно присутствует в мире компьютеров. За исключением крупных корпораций, небольших компаний, банков, больниц и колледжей, SQL используется практически везде, включая ваш смартфон на iOS или Android, и я не говорю только о приложениях.

Одним из основных недостатков SQL является то, что в базовом стандарте SQL нет никаких структур принятия решений или циклических конструкций, таких как if-else или for или while. Поэтому поставщики создали решения — или, скорее, языковые дополнения — которые расширяют стандартный SQL, такие как Microsoft Transact-SQL (T-SQL) или Oracle Procedural Language SQL (PLSQL).

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

Я технолог по базам данных, имеющий более 11 лет богатого практического опыта работы с технологиями баз данных.Я являюсь сертифицированным специалистом Microsoft и имею степень магистра компьютерных приложений.

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