С помощью SQL программист описывает только то, какие данные нужно извлечь или модифицировать. То, каким образом это сделать, решает СУБД непосредственно при обработке SQL-запроса. Однако не стоит думать, что это полностью универсальный принцип — программист описывает набор данных для выборки или модификации, однако ему при этом полезно представлять, как СУБД будет разбирать текст его запроса. Чем сложнее сконструирован запрос, тем больше он допускает вариантов написания, различных по скорости выполнения, но одинаковых по итоговому набору данных.
Недостатки
Несоответствие реляционной модели данных
Создатели реляционной модели данных Эдгар Кодд, Кристофер Дейт и их сторонники указывают на то, что SQL не является истинно реляционным языком. В частности они указывают на следующие проблемы SQL[3]:
- Повторяющиеся строки
- Неопределённые значения (nulls)
- Явное указание порядка колонок слева направо
- Колонки без имени и дублирующиеся имена колонок
- Отсутствие поддержки свойства «=»
- Использование указателей
- Высокая избыточность
В опубликованном Кристофером Дейтом и Хью Дарвеном Третьем Манифесте[4] они излагают принципы СУБД следующего поколения и предлагают язык Tutorial D, который является подлинно реляционным.
