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

Question

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

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

Answer 1

SQL Wikipedia entry кратко описывает некоторую историю:

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

Исходное имя явно указано Английский, объясняя синтаксис.

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

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

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

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

MULTIPLY PRICE BY QUANTITY GIVING COST. 

Answer 2

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

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

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

Answer 3

Я думаю, что способ структурирования 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 4

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

С очень первый взгляд вы можете сказать, будет ли запрос SELECT, INSERT, UPDATE или DELETE данные (все остальные SQL, например DDL, опущенные на цели).

---

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

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

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

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

Answer 7

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

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

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

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

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