Почему грамматика SQL наизнанку?

Question

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

Обычно в программировании, когда что-то кажется бессмысленным, за этим стоит историческая причина. Начинать с SELECT вместо FROM не имеет смысла. Кто-нибудь знает причину, по которой это было сделано?

Answer 1

Я думаю, что структура SQL-оператора имеет логический смысл, поскольку английские предложения структурированы. В основном

I WANT THIS
FROM HERE
WHERE WHAT I WANT MEETS THESE CRITERIA

Не думаю, что имеет смысл, по крайней мере, по-английски, говорить

FROM HERE
I WANT THIS
WHERE WHAT I WANT MEETS THESE CRITERIA  

Answer 2

Запись в Википедии SQL кратко описывает некоторую историю:

В 1970-х годах группа в исследовательской лаборатории IBM в Сан-Хосе разработала систему управления реляционными базами данных System R на основе модели, представленной Эдгаром Ф. Коддом в его влиятельной статье «Реляционная модель данных для больших общих банков данных». ». Дональд Д. Чемберлин и Рэймонд Ф. Бойс из IBM впоследствии создали язык структурированных английских запросов (SEQUEL) для манипулирования данными, хранящимися в System R. торговая марка британской авиастроительной компании Hawker Siddeley.

В оригинальном названии явно упоминается Английский , поясняющий синтаксис.

Копая немного глубже, мы находим FLOW-MATIC язык программирования.

FLOW-MATIC, первоначально известный как B-0 (Business Language version 0), , возможно, является первым английским языком обработки данных . Он был изобретен и определен Грейс Хоппер, и в 1955 году в Remington Rand началась разработка коммерческого варианта для UNIVAC I. К 1958 году компилятор и его документация были в основном доступны и использовались в коммерческих целях.

FLOW-MATIC послужил вдохновением для Common Business Oriented Language , одного из старейших языков программирования, все еще активно используемых. Следуя этому духу, SEQUEL был разработан с английским синтаксисом (1970-е годы современны по сравнению с 1950-ми и 1960-ми годами).

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

MULTIPLY PRICE BY QUANTITY GIVING COST.

Answer 3

Я должен не согласиться. Грамматика SQL не наизнанку.

Из самого первого взгляда вы можете определить, будет ли запрос ВЫБРАТЬ, ВСТАВИТЬ, ОБНОВИТЬ или УДАЛИТЬ данные (все остальное в SQL, например, DDL, специально пропущено).

---

Возвращаясь к вашей путанице с оператором SELECT: цель SQL - быть декларативной . Это означает, что вы выражаете то, что вы хотите, а не как вы этого хотите. Поэтому имеет смысл first указать, ЧТО ВЫ ХОТИТЕ (список атрибутов, которые вы выбираете ing) и затем предоставляют СУБД некоторую дополнительную информацию о том, где это следует искать ОТ.

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

---

Предложение ORDER BY в самом конце: как только данные пройдут через воронку, отсортируйте их.

JOINS (критерии JOIN) действительно принадлежат предложению FROM.

GROUPING: в основном данные пропускаются через воронку, прежде чем они попадают в другую воронку.

Синтаксис SQL сладок. В этом нет ничего внутри. Может быть, поэтому SQL так популярен даже после стольких десятилетий. Это довольно легко понять и понять. (Хотя я когда-то сталкивался с 7-страничным (размером A4) оператором SQL, который довольно долго занимал меня.)

Answer 4

Это похоже на английский. Я думаю, что это основная причина.

Как примечание, я помню, что первые предварительные просмотры LINQ были смоделированы непосредственно после него (select ... from ...). Это было изменено в более поздних превью, чтобы быть более похожим на язык программирования (так что область видимости идет вниз). В качестве причины, по которой они приняли это решение, Андерс Хейлсберг особо упомянул этот странный факт о SQL (который усложняет IntelliSense и не соответствует правилам области действия C #).

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

Answer 5

Порядок предложений в SQL абсолютно логичен. Помните, что SQL - это декларативный язык, где вы объявляете, что хотите, и система выясняет, как лучше всего его получить. Первое предложение - это предложение select, в котором вы перечисляете нужные столбцы в таблице результатов. Это основная цель запроса. Указав, как вы хотите, чтобы результат выглядел, вы в следующий раз укажите, откуда должны поступать данные. Предложение where ограничивает объем возвращаемых данных. Нет смысла думать о том, как ограничить ваши данные, если вы не знаете, откуда они берутся, поэтому они идут после предложения from. Предложение group by работает с операторами агрегирования в предложении select и может идти в любом месте после предложения from, однако лучше подумать об агрегации отфильтрованных данных, поэтому оно следует после предложения where. Пункт имения должен идти после группы по предложению. Условие order by показывает, как данные представляются и могут идти куда угодно после выбора.

Answer 6

История этого языка в стороне (хотя это увлекательно). Я думаю, что вам не хватает того, что SQL не говорит системе, что делать, а то, какой конечный результат вы хотите (и он выясняет, как сделай это)

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

Сначала SQL начинается с конечного результата, данных, которые вы хотите, порядка столбцов и т. Д. Это очень важно для того, кто создает отчет. «Я хочу имя, фамилию, затем возраст, потом .....». Это и есть цель запроса. Итак, начинается с того, формат результатов, которые вы хотите. Затем он уходит туда, где вы ожидаете найти данные, какие критерии искать, порядок их представления и т. Д.

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

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

Answer 7

Это согласуется с остальным синтаксисом SQL, согласно которому каждый оператор начинается с глагола (CREATE, DROP, UPDATE и т. Д.).

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

Мы могли бы иметь лучшее из обоих миров с синтаксисом, подобным SELECT FROM SomeTable: ColumnA, ColumnB, но уже слишком поздно менять его.

Как бы то ни было, порядок операторов SELECT в SQL не уникален. Это точно соответствует пониманию списка Python:

[(rec.a, rec.b) for rec in data where rec.a > 0]