Просто добавим к некоторым замечаниям о разнице между так называемыми процедурными языками, с одной стороны, и SQL (который по-разному описывается как декларативный или описательный язык), с другой.
SQL определяет набор операторов высокого уровня для работы с массивами данных. В этом смысле они являются «высокоуровневыми», потому что работают с массивами в сжатой форме, что не характерно для языков общего назначения или процедурных языков. Как и все операторы (независимо от того, основаны они на массивах или нет), обычно существует более одного алгоритма, способного реализовать оператор.
В отличие от языков программирования "общего назначения", с которыми сталкивается подавляющее большинство программистов, существование этих операторов массива - в частности, возможность объединять их алгебраически в выражение, которое определяет составную операцию (или запрос), и отсутствие каких-либо явных алгоритмов для итерации - когда-то было определяющей особенностью SQL.
В наши дни это различие менее резкое, с возрождающимся интересом к функциональным языкам и функциям, но большинство все еще рассматривает SQL как своего рода зверя среди коммерчески популярных инструментов.
Это Часто говорят, что в SQL вы определяете , какие результаты вы не хотите , как , чтобы получить их. Но это верно для каждого языка. Это верно даже для операторов машинного кода, если вы учитываете, как реализация в схемах может варьироваться - и действительно ли она варьируется в зависимости от конструкции ЦП. Это, безусловно, верно для всех скомпилированных языков, где компиляторы используют множество различных алгоритмов машинного кода для фактической реализации операций, указанных в исходном коде - l oop развертывание, например,
Функция, которая продолжает различаться guish SQL (и реляционные базы данных, которые его реализуют) заключается в том, что алгоритм, который реализует операцию, определяется во время каждого выполнения , и он делает это не только алгебраически c манипулирование запросами (что не отличается от того, что делают компиляторы), но также путем непрерывного генерирования и анализа статистики о данных, которые обрабатываются, и последствиях предыдущих выполнений.
Другими словами, механизм выполнения баз данных постоянно осуществляет поиск лучших практических алгоритмов (и их комбинаций) для реализации своей общей рабочей нагрузки. Он способен приспосабливаться не только к прошлому опыту, но и реагировать на изменения (например, в объемах данных, в степени параллелизма и транзакционного конфликта или в системных системных ограничениях c, таких как доступная память или общая рабочая нагрузка).
Результатом всего этого является то, что существует определенный c порядок оценки в SQL, как и на любом другом языке. Именно этот порядок определяет правильный результат. Но если написано не в так называемом стиле RBAR (и даже тогда, но в более ограниченной степени ...), ядро базы данных обладает огромными возможностями для реализации ярлыков и оптимизации производительности, при условии, что они не изменяют конечный результат.
Многие операторы попадают в класс, где во многих случаях можно определить результат без оценки всех операндов. Я не уверен, что формальное слово, чтобы описать это свойство - частичная оценка , может быть, - но случайно это называется короткое замыкание . Оператор OR имеет это свойство.
Другое свойство операции OR состоит в том, что она ассоциативна . То есть порядок, в котором применяется ряд из них, не имеет значения - он ведет себя как оператор сложения, где вы можете добавлять числа в любом порядке, не влияя на результат.
С рядом условий ИЛИ они могут быть переупорядочены и частично оценены при условии, что оценка любого конкретного операнда не вызывает побочных эффектов или зависит от скрытых переменных. Поэтому вполне вероятно, что ядро базы данных может изменить их порядок или частично оценить.
Если операнды вызывают побочные эффекты или зависят от скрытых переменных (функции, которые получают текущую дату или время, являющиеся основным примером последних), они часто вызывают проблемы в запросах - либо потому, что механизм базы данных делает не осознавать, что у них есть побочные эффекты или скрытые переменные, или потому что база данных действительно осознает это, но не обрабатывает случай так, как ожидает программист. В таких случаях запрос может быть полностью переписан (обычно разбит на несколько операторов), чтобы вызвать определенный c порядок оценки или гарантировать полную оценку.