Введение в SQL
Что такое SQL (Structured Query Language)?
SQL (Structured Query Language) — язык структурированных запросов.
SQL (Structured Query Language, язык структурированных запросов) — это специальный язык, используемый для определения данных, доступа к данным и их обработки. Язык SQL относится к непроцедурным (nonprocedural) языкам — он лишь описывает нужные компоненты (например, таблицы) и желаемые результаты, не указывая, как именно эти результаты должны быть получены. Каждая реализация SQL является надстройкой над процессором базы данных (database engine), который интерпретирует операторы SQL и определяет порядок обращения к структурам БД для корректного и эффективного формирования желаемого результата.
Стандарт SQL определяется ANSI — American National Standarts Institute (Американским Национальным Институтом Стандартов) и в настоящее время принят ISO — International Standarts Organization (Международной Организацией по Стандартизации).
SQL — непроцедурный язык: серверу базы данных сообщается, что нужно сделать и каким образом. Для обработки запроса сервер базы данных транслирует команды SQL во внутренние процедуры. Благодаря тому, что SQL скрывает детали обработки данных, его легко использовать.
Что можно делать с помощью SQL?
Команды SQL
Команды SQL разделяются на следующие группы:
Основные ключевые слова, используемые в статье«Введение в SQL»:
mysql_query
mysql_query — Посылает запрос MySQL
Данный модуль устарел, начиная с версии PHP 5.5.0, и удалён в PHP 7.0.0. Используйте вместо него MySQLi или PDO_MySQL. Смотрите также инструкцию MySQL: выбор API. Альтернативы для данной функции:
Описание
Список параметров
Запрос не должен заканчиваться точкой с запятой. Данные в запросе должны быть корректно проэкранированы.
Возвращаемые значения
Для запросов SELECT, SHOW, DESCRIBE, EXPLAIN и других запросов, возвращающих результат из нескольких рядов, mysql_query() возвращает дескриптор результата запроса ( resource ), или false в случае возникновения ошибки.
Для других типов SQL-запросов, INSERT, UPDATE, DELETE, DROP и других, mysql_query() возвращает true в случае успешного выполнения и false в случае возникновения ошибки.
Полученный дескриптор результата нужно передать в функцию mysql_fetch_assoc() или любую другую функцию, работающую с результатами запросов.
Используйте mysql_num_rows() для выяснения количества рядов в результате SELECT-запроса или mysql_affected_rows() для выяснения количества обработанных рядов запросами DELETE, INSERT, REPLACE и UPDATE.
Примеры
Пример #1 Неверный запрос
Пример #2 Верный запрос
// Эти данные, к примеру, могли быть получены от пользователя
$firstname = ‘fred’ ;
$lastname = ‘fox’ ;
Смотрите также
User Contributed Notes 26 notes
Simulating an atomic operation for application locks using mysql.
$q = «update `table` set `LOCK`=’F’ where `ID`=’1′»;
$lock = mysql_affected_rows();
If we assume
NOT LOCKED = «» (empty string)
LOCKED = ‘F’
then if the column LOCK had a value other than F (normally should be an empty string) the update statement sets it to F and set the affected rows to 1. Which mean than we got the lock.
If affected rows return 0 then the value of that column was already F and somebody else has the lock.
The secret lies in the following statement taken from the mysql manual:
«If you set a column to the value it currently has, MySQL notices this and does not update it.»
Of course all this is possible if the all application processes agree on the locking algorithm.
mysql_query doesnt support multiple queries, a way round this is to use innodb and transactions
this db class/function will accept an array of arrays of querys, it will auto check every line for affected rows in db, if one is 0 it will rollback and return false, else it will commit and return true, the call to the function is simple and is easy to read etc
———-
function transaction($q_array) <
$retval = 1;
if($retval == 0) <
$this->rollback();
return false;
>else <
$this->commit();
return true;
>
>
/* Create database connection object */
$database = new MySQLDB;
// then from anywhere else simply put the transaction queries in an array or arrays like this:
$q = array (
array(«query» => «UPDATE table WHERE something = ‘something'»),
array(«query» => «UPDATE table WHERE something_else = ‘something_else'»),
array(«query» => «DELETE FROM table WHERE something_else2 = ‘something_else2′»),
);
Regarding the idea for returning all possible values of an enum field, the mySQL manual says that «SHOW COLUMNS FROM table LIKE column» should be used to do this.
The function below (presumes db connection) will return an array of the possible values of an enum.
function GetEnumValues($Table,$Column)
<
$dbSQL = «SHOW COLUMNS FROM «.$Table.» LIKE ‘».$Column.»‘»;
$dbQuery = mysql_query($dbSQL);
$EnumValues = substr($EnumValues, 6, strlen($EnumValues)-8);
$EnumValues = str_replace(«‘,'»,»,»,$EnumValues);
This is just a quick example to show how to do it, some tidying up needs to be done (ie checking if the field is actually an enum) before it is perfect.
This project implements a wrapper to mysql functions in PHP7.0+
tested and working fine =)
When trying to INSERT or UPDATE and trying to put a large amount of text or data (blob) into a mysql table you might run into problems.
In mysql.err you might see:
Packet too large (73904)
You would just replace maxsize with the max size you want to insert, the default is 65536
It should be noted that mysql_query can generate an E_WARNING (not documented). The warning that I hit was when the db user did not have permission to execute a UDF.
Expected behavior would be like an Invalid SQL statement, where there is no E_WARNING generated by mysql_query.
Warning: mysql_query() [function.mysql-query]: Unable to save result set in filename.php
The mysql_errno is 1370 and the mysql_error is:
execute command denied to user ‘username’@’%’ for routine ‘database_name.MyUDF’
If, like me, you come from perl, you may not like having to use sprintf to ‘simulate’ placeholders that the DBI package from perl provides. I have created the following wrapper function for mysql_query() that allows you to use ‘?’ characters to substitute values in your DB queries. Note that this is not how DBI in perl handles placeholders, but it’s pretty similar.
// oops, wrong userid or passwd
else <
echo «Invalid username and password combination.\n» ;
>
?>
When you run a select statement and receive a response, the data types of your response will be a string regardless of the data type of the column.
Use this to neatly insert data into a mysql table:
I believe there is a typo in celtic at raven-blue dot com version with:
I think you really ment:
Keep in mind when dealing with PHP & MySQL that sending a null-terminated string to a MySQL query can be misleading if you use echo($sql) in PHP because the null terminator may not be visible.
For example (this assumes connection is already made),
$string1 = «mystring\0»;
$string2 = «mystring»;
$query1 = «SELECT * FROM table WHERE mystring='».$string1.»‘»
$query2 = «SELECT * FROM table WHERE mystring='».$string2.»‘»
//but printing these queries to the screen will provide the same result
echo($result1);
echo($result2);
Not knowing this could lead to some mind-numbing troubleshooting when dealing with any strings with a null terminator. So now you know! 🙂
this could be a nice way to print values from 2 tables with a foreign key. i have not yet tested correctly but it should work fine.
Here’s a parameterised query function for MySQL similar to pg_query_params, I’ve been using something similar for a while now and while there is a slight drop in speed, it’s far better than making a mistake escaping the parameters of your query and allowing an SQL injection attack on your server.
# Parameterised query implementation for MySQL (similar PostgreSQL’s PHP function pg_query_params)
# Example: mysql_query_params( «SELECT * FROM my_table WHERE col1=$1 AND col2=$2», array( 42, «It’s ok» ) );
For all you programmers out there getting the ‘Command out of synch’ errors when executing a stored procedure call:
There are known bugs related to this issue, and the best workaround for avoiding this error seems to be switching to mysqli.
Still, I needed mysql to also handle these calls correctly.
The error is normally related to wrong function call sequences, though the bug report at http://bugs.php.net/bug.php?id=39727 shows otherwise.
For me, after commenting out hundreds of lines and several introspection calls to parse the procedure information (using information_schema and ‘SHOW’ extensions), I still got the same error.
The first result is returned, because I initiated my connection using the MYSQL_MULTI_RESULTS value of 131072 (forget this and you will never get any output, but an error message stating mysql cannot return results in this context)
After testing with this code (sproc2 simply calls ‘SELECT * FROM sometable’), I found the error must be in the mysql library/extension. Somehow, mysql does not handle multiple resultsets correctly, or is at least missing some functionality related to handling multiple results.
So if you ever make a uniform database accessing interface and implement stored procedures/prepared statements (or classes for it), this could be a solution if you really wish to enable stored procedures.
Still, be aware that this is really a serious flaw in your design (and IMHO, the mysql extension)
Also see the documentation for mysqli on mysqli_query, which seems to be working fine.
here’s a script for parsing a *.sql file (tested only on dumps created with phpMyAdmin) which is short and simple (why do people say «here’s a short and simple script» and it has a 100 lines?). the script skips comments and allows ; to be present within the querys
I much prefer to use the same syntax for single INSERT, REPLACE and UPDATE queries as it is easier to read and keeps my code shorter (no seperate building of insert and update values)
INSERT INTO table SET x=’1′, y=3
UPDATE table SET x=’2′ WHERE y=3
So if your using a function to build your query, you will only ever need to code the «field=value, field2=value2» part for any query.
/* malformed query /*
$rs = mysql_query(«SELECT `foo` FRO `bar`»);
if($rs) <
echo «This will never be echoed»;
>
?>
One way to reduce the dangers of queries like the dlete command above that dletes the whole DB is to use limits wherever possible.
EG. If you have a routine that is only deisnged to delete 1 record, add ‘LIMIT 1’ to the end of the command. This way you’ll only lose one record if someone does something stupid.
Just don’t trust ANY data that is sent to your script.
If you need to execute sevaral SQL commands in a row (usually called batcg SQL) using PHP you canot use mysql_query() since it can execute single command only.
Here is simple but effective function that can run batch SQL commands. Take cere, if string contains semicolon (;) anywhere except as command delimiter (within string expression for example) function will not work.
For those of you whom spent hours bashing your brains against the keyboard wondering why your non-English characters are output as question marks. Try the following:
?>
Simply run the query «set names ‘utf8’ » against the MySQL DB and your output should appear correct.
Как думать на SQL?
Если вы похожи на меня, то согласитесь: SQL — это одна из тех штук, которые на первый взгляд кажутся легкими (читается как будто по-английски!), но почему-то приходится гуглить каждый простой запрос, чтобы найти правильный синтаксис.
А потом начинаются джойны, агрегирование, подзапросы, и получается совсем белиберда. Вроде такой:
Буэ! Такое спугнет любого новичка, или даже разработчика среднего уровня, если он видит SQL впервые. Но не все так плохо.
Легко запомнить то, что интуитивно понятно, и с помощью этого руководства я надеюсь снизить порог входа в SQL для новичков, а уже опытным предложить по-новому взглянуть на SQL.
Не смотря на то, что синтаксис SQL почти не отличается в разных базах данных, в этой статье для запросов используется PostgreSQL. Некоторые примеры будут работать в MySQL и других базах.
1. Три волшебных слова
2. Наша база
Давайте взглянем на базу данных, которую мы будем использовать в качестве примера в этой статье:
У нас есть книжная библиотека и люди. Также есть специальная таблица для учета выданных книг.
3. Простой запрос
Давайте начнем с простого запроса: нам нужны имена и идентификаторы (id) всех книг, написанных автором “Dan Brown”
Запрос будет таким:
| id | title |
|---|---|
| 2 | The Lost Symbol |
| 4 | Inferno |
Довольно просто. Давайте разберем запрос чтобы понять, что происходит.
3.1 FROM — откуда берем данные
Сейчас это может показаться очевидным, но FROM будет очень важен позже, когда мы перейдем к соединениям и подзапросам.
FROM указывает на таблицу, по которой нужно делать запрос. Это может быть уже существующая таблица (как в примере выше), или таблица, создаваемая на лету через соединения или подзапросы.
3.2 WHERE — какие данные показываем
WHERE просто-напросто ведет себя как фильтр строк, которые мы хотим вывести. В нашем случае мы хотим видеть только те строки, где значение в колонке author — это “Dan Brown”.
3.3 SELECT — как показываем данные
Весь запрос можно визуализировать с помощью простой диаграммы:
4. Соединения (джойны)
Теперь мы хотим увидеть названия (не обязательно уникальные) всех книг Дэна Брауна, которые были взяты из библиотеки, и когда эти книги нужно вернуть:
| Title | Return Date |
|---|---|
| The Lost Symbol | 2016-03-23 00:00:00 |
| Inferno | 2016-04-13 00:00:00 |
| The Lost Symbol | 2016-04-19 00:00:00 |
borrowings JOIN books ON borrowings.bookid=books.bookid — это, считай, новая таблица, которая была сформирована комбинированием всех записей из таблиц «books» и «borrowings», в которых значения bookid совпадают. Результатом такого слияния будет:
А потом мы делаем запрос к этой таблице так же, как в примере выше. Это значит, что при соединении таблиц нужно заботиться только о том, как провести это соединение. А потом запрос становится таким же понятным, как в случае с «простым запросом» из пункта 3.
Давайте попробуем чуть более сложное соединение с двумя таблицами.
Теперь мы хотим получить имена и фамилии людей, которые взяли из библиотеки книги автора “Dan Brown”.
На этот раз давайте пойдем снизу вверх:
Шаг Step 1 — откуда берем данные? Чтобы получить нужный нам результат, нужно соединить таблицы “member” и “books” с таблицей “borrowings”. Секция JOIN будет выглядеть так:
Результат соединения можно увидеть по ссылке.
Шаг 2 — какие данные показываем? Нас интересуют только те данные, где автор книги — “Dan Brown”
Шаг 3 — как показываем данные? Теперь, когда данные получены, нужно просто вывести имя и фамилию тех, кто взял книги:
Супер! Осталось лишь объединить три составные части и сделать нужный нам запрос:
| First Name | Last Name |
|---|---|
| Mike | Willis |
| Ellen | Horton |
| Ellen | Horton |
Отлично! Но имена повторяются (они не уникальны). Мы скоро это исправим.
5. Агрегирование
Грубо говоря, агрегирования нужны для конвертации нескольких строк в одну. При этом, во время агрегирования для разных колонок используется разная логика.
Давайте продолжим наш пример, в котором появляются повторяющиеся имена. Видно, что Ellen Horton взяла больше одной книги, но это не самый лучший способ показать эту информацию. Можно сделать другой запрос:
Что даст нам нужный результат:
| First Name | Last Name | Number of books borrowed |
|---|---|---|
| Mike | Willis | 1 |
| Ellen | Horton | 2 |
Каждая строка в результате представляет собой результат агрегирования каждой группы.
В примере выше функция count обрабатывала все строки (так как мы считали количество строк). Другие функции вроде sum или max обрабатывают только указанные строки. Например, если мы хотим узнать количество книг, написанных каждым автором, то нужен такой запрос:
| author | sum |
|---|---|
| Robin Sharma | 4 |
| Dan Brown | 6 |
| John Green | 3 |
| Amish Tripathi | 2 |
Здесь функция sum обрабатывает только колонку stock и считает сумму всех значений в каждой группе.
6. Подзапросы
Подзапросы это обычные SQL-запросы, встроенные в более крупные запросы. Они делятся на три вида по типу возвращаемого результата.
6.1 Двумерная таблица
Есть запросы, которые возвращают несколько колонок. Хороший пример это запрос из прошлого упражнения по агрегированию. Будучи подзапросом, он просто вернет еще одну таблицу, по которой можно делать новые запросы. Продолжая предыдущее упражнение, если мы хотим узнать количество книг, написанных автором “Robin Sharma”, то один из возможных способов — использовать подзапросы:
| author | sum |
|---|---|
| Robin Sharma | 4 |
6.2 Одномерный массив
Запросы, которые возвращают несколько строк одной колонки, можно использовать не только как двумерные таблицы, но и как массивы.
Допустим, мы хотим узнать названия и идентификаторы всех книг, написанных определенным автором, но только если в библиотеке таких книг больше трех. Разобьем это на два шага:
1. Получаем список авторов с количеством книг больше 3. Дополняя наш прошлый пример:
| author |
|---|
| Robin Sharma |
| Dan Brown |
Можно записать как: [‘Robin Sharma’, ‘Dan Brown’]
2. Теперь используем этот результат в новом запросе:
| title | bookid |
|---|---|
| The Lost Symbol | 2 |
| Who Will Cry When You Die? | 3 |
| Inferno | 4 |
Это то же самое, что:
6.3 Отдельные значения
Бывают запросы, результатом которых являются всего одна строка и одна колонка. К ним можно относиться как к константным значениям, и их можно использовать везде, где используются значения, например, в операторах сравнения. Их также можно использовать в качестве двумерных таблиц или массивов, состоящих из одного элемента.
Давайте, к примеру, получим информацию о всех книгах, количество которых в библиотеке превышает среднее значение в данный момент.
Среднее количество можно получить таким образом:
Теперь, наконец, можно написать весь запрос:
Это то же самое, что:
| bookid | title | author | published | stock |
|---|---|---|---|---|
| 3 | Who Will Cry When You Die? | Robin Sharma | 2006-06-15 00:00:00 | 4 |
7. Операции записи
Большинство операций записи в базе данных довольно просты, если сравнивать с более сложными операциями чтения.
7.1 Update
Синтаксис запроса UPDATE семантически совпадает с запросом на чтение. Единственное отличие в том, что вместо выбора колонок SELECT ‘ом, мы задаем знаения SET ‘ом.
Если все книги Дэна Брауна потерялись, то нужно обнулить значение количества. Запрос для этого будет таким:
7.2 Delete
7.3 Insert
8. Проверка
Вот он в более удобном для чтения виде:
Этот запрос выводит список людей, которые взяли из библиотеки книгу, у которой общее количество выше среднего значения.
| Full Name |
|---|
| Lida Tyler |
Надеюсь, вам удалось разобраться без проблем. Но если нет, то буду рад вашим комментариям и отзывам, чтобы я мог улучшить этот пост.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
SQL (Structured Query Language)
 | |
| Парадигма | Мультипарадигмальный |
|---|---|
| Спроектировано | Дональд Чемберлин Рэймонд Бойс |
| Разработчики | ISO/IEC |
| Первый появившийся | 1974 |
| Стабильная версия | SQL:2008 / 2008 |
| Печать дисциплины | Статическая, строгая |
| OS | Кроссплатформенный |
| Расширение файла | .sql |
| Главная реализация | |
| Много | |
| Диалект | |
| SQL-86, SQL-89, SQL-92, SQL:1999, SQL:2003, SQL:2008 | |
| Под влиянием | |
| Datalog | |
| Влияние | |
| Agena, CQL, LINQ, Windows PowerShell [1] | |
| Разработчик | ISO/IEC | |||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Начальная версия | 1986 | |||||||||||||||||||||||||||||
| Последний релиз | СодержаниеИсторияПервые разработкиВ начале 1970-х годов в одной из исследовательских лабораторий компании IBM была разработана экспериментальная реляционная СУБД IBM System R, для которой затем был создан специальный язык SEQUEL, позволявший относительно просто управлять данными в этой СУБД. Аббревиатура SEQUEL расшифровывалась как Structured English QUEry Language — «структурированный английский язык запросов». Позже по юридическим соображениям [2] язык SEQUEL был переименован в SQL. Когда в 1986 году первый стандарт языка SQL был принят ANSI, официальным произношением стало [,es kju:’ el] — эс-кью-эл. Несмотря на это, даже англоязычные специалисты зачастую продолжают читать SQL как сиквел (по-русски часто говорят «эс-ку-эль»). C одной стороны, SQL был ориентирован на удобную и понятную пользователям формулировку запросов к реляционным БД. С другой стороны, практически с самого начала он был так называемым «полным языком БД». Это означает, что SQL включал: Целью разработки было создание простого непроцедурного языка, которым мог воспользоваться любой пользователь, даже не имеющий навыков программирования. Собственно разработкой языка запросов занимались Дональд Чэмбэрлин и Рэй Бойс (|Ray Boyce). Пэт Селинджер (Pat Selinger) занималась разработкой стоимостного оптимизатора (Шаблон:Lang-en2), Рэймонд Лори (Raymond Lorie) занимался компилятором запросов. Стоит отметить, что SEQUEL был не единственным языком подобного назначения. В Калифорнийском Университете Беркли была разработана некоммерческая СУБД Ingres (являвшаяся, между прочим, дальним прародителем популярной сейчас некоммерческой СУБД PostgreSQL), которая являлась реляционной СУБД, но использовала свой собственный язык QUEL, который, однако, не выдержал конкуренции по количеству поддерживающих его СУБД по сравнению с языком SQL. Первыми СУБД, поддерживающими новый язык, стали в 1979 году Oracle V2 для машин VAX от компании Relational Software Inc. (впоследствии ставшей компанией Oracle) и System/38 от IBM, основанная на System/R. СтандартизацияПоскольку к началу 1980-х годов существовало несколько вариантов СУБД от разных производителей, причём каждый из них обладал собственной реализацией языка запросов, было принято решение разработать стандарт языка, который будет гарантировать переносимость ПО с одной СУБД на другую (при условии, что они будут поддерживать этот стандарт). В 1983 году Международная организация по стандартизации (ISO) и Американский национальный институт стандартов (ANSI) приступили к разработке стандарта языка SQL. По прошествии множества консультаций и отклонения нескольких предварительных вариантов, в 1986 году ANSI представил свою первую версию стандарта, описанную в документе ANSI X3.135-1986 под названием «Database Language SQL» (Язык баз данных SQL). Неофициально этот стандарт SQL-86 получил название SQL1. Год спустя была завершена работа над версией стандарта ISO 9075-1987 под тем же названием. Разработка этого стандарта велась под патронажем Технического Комитета TC97 (Technical Committee TC97), областью деятельности которого являлись процессы вычисления и обработки информации (Computing and Information Processing). Именно его подразделение, именуемое как Подкомитет SC21 (Subcommittee SC21), курировало разработку стандарта, что стало залогом идентичности стандартов ISO и ANSI для SQL1 (SQL-86). Стандарт SQL1 разделялся на два уровня. Первый уровень представлял собой подмножество второго уровня, описывавшего весь документ в целом. То есть, такая структура предусматривала, что не все спецификации стандарта SQL1 будут относиться к Уровню 1. Тем самым поставщик, заявлявший о поддержке данного стандарта, должен был заявлять об уровне, которому соответствует его реализация языка SQL. Это значительно облегчило принятие и поддержку стандарта, поскольку производители могли реализовывать его поддержку в два этапа. Со временем к стандарту накопилось несколько замечаний и пожеланий, особенно с точки зрения обеспечения целостности и корректности данных, в результате чего в 1989 году данный стандарт был расширен, получив название SQL89. В частности, в него была добавлена концепция первичного и внешнего ключей. ISO-версия документа получила название ISO 9075:1989 «Database Language SQL with Integrity Enhancements» (Язык баз данных SQL с добавлением контроля целостности). Параллельно была закончена и ANSI-версия. Сразу после завершения работы над стандартом SQL1 в 1987 году была начата работа над новой версией стандарта, который должен был заменить стандарт SQL89, получив название SQL2, поскольку дата принятия документа на тот момент была неизвестна. Таким образом, фактически SQL89 и SQL2 разрабатывались параллельно. Новая версия стандарта была принята в 1992 году, заменив стандарт SQL89. Новый стандарт, озаглавленный как SQL92, представлял собой по сути расширение стандарта SQL1, включив в себя множество дополнений, имевшихся в предыдущих версиях инструкций. Как и SQL1, SQL92 также был разделён на несколько уровней, однако, во-первых, число уровней было увеличено с двух до трёх, а во-вторых, они получили названия вместо порядковых цифр: начальный (entry), средний (intermediate), полный (full). Уровень «полный», как и Уровень 2 в SQL1 подразумевал весь стандарт целиком. Уровень «начальный» представлял собой подмножество уровня «средний», в свою очередь, представлявшего собой подмножество уровня «полный». Уровень «начальный» был сравним с Уровнем 2 стандарта SQL1, но спецификации этого уровня были несколько расширены. Таким образом, цепочка включений уровней стандартов выглядела примерно следующим образом: SQL1 Уровень 1 → SQL1 Уровень 2 → SQL92 «Начальный» → SQL92 «Средний» → SQL92 «Полный». После принятия стандарта SQL92 к нему были добавлены ещё несколько документов, расширявших функциональность языка. Так, в 1995 году был принят стандарт SQL/CLI (Call Level Interface, интерфейс уровня вызовов), впоследствии переименованный в CLI95. На следующий год был принят стандарт SQL/PSM (Persistent Stored Modules, постоянно хранимые модули), получивший название PSM-96. [3] Следующим стандартом стал SQL:1999 (SQL3). В настоящее время действует стандарт, принятый в 2003 году (SQL:2003) с небольшими модификациями, внесёнными позже (SQL:2008). История версий стандарта:
Для поставщиков СУБД стандарт — это путеводная звезда, которая гарантирует правильное направление работ. А вот эффективность реализации стандарта — это гарантия успеха. SQL нельзя в полной мере отнести к традиционным языкам программирования, он не содержит традиционные операторы, управляющие ходом выполнения программы, операторы описания типов и многое другое, он содержит только набор стандартных операторов доступа к данным, хранящимся в базе данных. Операторы SQL встраиваются в базовый язык программирования, которым может быть любой стандартный язык типа C++, PL, COBOL и т. д. Кроме того, операторы SQL могут выполняться непосредственно в интерактивном режиме. АльтернативаСледует различать альтернативы SQL как языка и как альтернативу самой реляционной модели. Ниже предлагаются реляционные альтернативы языку SQL. См. Навигационную базу данных и NoSQL для альтернатив реляционной модели. СтруктураSQL включает в себя выражения, решающие широкий круг задач: Команды языка SQL чатсо разделяют на наиболее крупные сегменты: СинтаксисСтруктура программыData definition languageData Definition Language используется для модификации схемы реляционной базы данных. Этот раздел языка состоит из четырёх типов утверждений: CREATE, ALTER, DROP, RENAME. CreateКоманда CREATE используется для создания новой базы данных, таблицы, индекса или хранимой процедуры. ALTERКоманда ALTER используется для модификации уже существующего в БД объекта. Команда DROP уничтожает существующий объект (будь то база данных, таблица или иной объект). RENAMEКоманда RENAME используется для переименования таблицы. Data manipulation languageData Manipulation Language используется для составления запросов к СУБД или модификации её содержимого. Раздел языка состоит из четырёх типов утверждений: SELECT, INSERT, UPDATE и DELETE. SELECTSELECT извлекает 0 или более строк из различных таблиц или отображений. Декларативное утверждение SELECT формулирует запрос с помощью условий FROM, JOIN, WHERE, GROUP BY, HAVING, ORDER_BY, DISTINCT и др. Возможны вложенные запросы, хотя их производительность обычно уступает классическому подходу с применением JOIN. Вложенный запрос также называют подзапросом. INSERTINSERT используется для добавления новых строк в таблицу. UPDATEUPDATE используется для модификации уже существующей строки. DELETEDELETE удаляет заданный условием набор строк. MERGEMERGE объединяет элементы нескольких таблиц. Data control languageСинтаксис Data Control Language используется для ограничения прав пользователей базы данных. Содержит два основных утверждения: GRANT и REVOKE. GRANTGRANT предоставляет привилегии пользователю. Все команды SQL выполняются от имени определённого пользователя. REVOKEREVOKE снимает привилегии с пользователя. Для полного снятия привилегии необходимо её снятие с понижаемого в полномочиях пользователя всеми пользователями, её давшими. Управление транзакциямиПреимущества и недостаткиПреимуществаНесмотря на наличие диалектов и различий в синтаксисе, в большинстве своём тексты SQL-запросов, содержащие DDL и DML, могут быть достаточно легко перенесены из одной СУБД в другую. Существуют системы, разработчики которых изначально ориентировались на применение по меньшей мере нескольких СУБД (например: система электронного документооборота Documentum может работать как с Oracle Database, так и с Microsoft SQL Server и DB2). Естественно, что при применении некоторых специфичных для реализации возможностей такой переносимости добиться уже очень трудно. Наличие стандартов и набора тестов для выявления совместимости и соответствия конкретной реализации SQL общепринятому стандарту только способствует «стабилизации» языка. Правда, стоит обратить внимание, что сам по себе стандарт местами чересчур формализован и раздут в размерах (например, базовая часть стандарта SQL:2003 состоит из более чем 1300 страниц текста). С помощью SQL программист описывает только то, какие данные нужно извлечь или модифицировать. То, каким образом это сделать, решает СУБД непосредственно при обработке SQL-запроса. Однако не стоит думать, что это полностью универсальный принцип — программист описывает набор данных для выборки или модификации, однако ему при этом полезно представлять, как СУБД будет разбирать текст его запроса. Чем сложнее сконструирован запрос, тем больше он допускает вариантов написания, различных по скорости выполнения, но одинаковых по итоговому набору данных. НедостаткиСоздатели реляционной модели данных Эдгар Кодд, Кристофер Дейт и их сторонники указывают на то, что SQL не является истинно реляционным языком. В частности, они указывают на следующие дефекты SQL с точки зрения реляционной теории [5] : В опубликованном Кристофером Дейтом и Хью Дарвеном Третьем манифесте [6] они излагают принципы СУБД следующего поколения и предлагают язык Tutorial D, который является подлинно реляционным. Хотя SQL и задумывался как средство работы конечного пользователя, в конце концов он стал настолько сложным, что превратился в инструмент программиста. Отступления от стандартов Несмотря на наличие международного стандарта ANSI SQL-92, многие разработчики СУБД вносят изменения в язык SQL, применяемый в разрабатываемой СУБД, тем самым отступая от стандарта. Таким образом появляются специфичные для каждой конкретной СУБД диалекты языка SQL. Сложность работы с иерархическими структурами Ранее диалекты SQL большинства СУБД не предлагали способа манипуляции древовидными структурами. Некоторые поставщики СУБД предлагали свои решения (например, в Oracle Database используется выражение CONNECT BY). В настоящее время в ANSI стандартизована рекурсивная конструкция WITH из диалекта SQL DB2. В Microsoft SQL Server рекурсивные запросы (Recursive Common Table Expressions) появились лишь в версии 2005. Распределенная обработка SQLАрхитектура распределенной реляционной базы данных (DRDA) была разработана рабочей группой в IBM в период с 1988 по 1994 год. DRDA позволяет связанным с сетью реляционным базам данных взаимодействовать для выполнения запросов SQL. Интерактивный пользователь или программа может выдавать SQL-запросы локальному RDB и получать таблицы данных и индикаторы состояния в ответ от удаленных RDB. Операторы SQL также могут быть скомпилированы и сохранены в удаленных RDB как пакеты, а затем вызваны именем этого пакета. Это важно для эффективной работы прикладных программ, которые вызывают сложные высокочастотные запросы. Это особенно важно, когда доступ к таблицам находится в удаленных системах. Сообщения, протоколы и структурные компоненты DRDA определяются архитектурой распределенного управления данными. |