Почему грамматика SQL вывернута наизнанку?
https://stackoverflow.com/questions/959591
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Практически в любом формально структурированном наборе информации вы начинаете читать либо с начала к концу, либо изредка с конца к началу (адреса улиц, например). Но в SQL, особенно в запросах SELECT, чтобы правильно понять это означает, что вам нужно начать с середины, с предложения FROM.Это может затруднить чтение длинных запросов, особенно если они содержат вложенные запросы SELECT.
Обычно в программировании, когда что-то кажется бессмысленным, за этим стоит историческая причина.Начинать с SELECT вместо FROM не имеет смысла.Кто-нибудь знает причину, по которой это сделано именно так?
Решение
А SQL-запись в Википедии кратко описывает некоторую историю:
В 1970-е годы группа из исследовательской лаборатории IBM в Сан-Хосе разработала систему управления реляционными базами данных System R, основанную на модели, предложенной Эдгаром Ф.Кодд в своей влиятельной статье «Реляционная модель данных для больших общих банков данных».Дональд Д.Чемберлин и Рэймонд Ф.Бойс из IBM впоследствии создал Структурированный английский язык запросов (ПРОДОЛЖЕНИЕ) манипулировать и управлять данными, хранящимися в System R.Аббревиатура SEQUEL позже была изменена на SQL, поскольку «SEQUEL» было торговой маркой британской авиастроительной компании Hawker Siddeley.
Оригинальное имя явно упомянуто Английский, объясняя синтаксис.
Копнув немного глубже, мы находим ФЛОУ-МАТИК язык программирования.
FLOW-MATIC, первоначально известный как B-0 (версия делового языка 0), возможно, это первый англоподобный язык обработки данных..Он был изобретен и описан Грейс Хоппер, а разработка коммерческого варианта UNIVAC I началась в Remington Rand в 1955 году.К 1958 году компилятор и документация к нему стали общедоступны и использовались в коммерческих целях.
FLOW-MATIC послужил вдохновением для создания Общий бизнес-ориентированный язык, один из старейших языков программирования, который до сих пор активно используется.Поддерживая этот дух, ПРОДОЛЖЕНИЕ был разработан с использованием синтаксиса, подобного английскому (1970-е годы - это современность по сравнению с 1950-ми и 1960-ми годами).
В перспективе «современные» системы программирования по-прежнему получают доступ к базам данных, используя давние идеи, лежащие в основе
MULTIPLY PRICE BY QUANTITY GIVING COST.
Другие советы
Я думаю, что способ структурирования оператора 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
Я должен не согласиться.Грамматика SQL не вывернута наизнанку.
Из самый первый взгляд вы можете определить, будет ли запрос ВЫБРАТЬ, ВСТАВИТЬ, ОБНОВИТЬ или УДАЛИТЬ данные (вся остальная часть SQL, напримерDDL, намеренно опущен).
Вернемся к путанице с оператором SELECT:Цель SQL — быть декларативный.Это означает, что вы выражаете ЧТО хотите, а не КАК вы этого хотите.Поэтому имеет смысл первый укажите, ЧТО ВЫ ХОТИТЕ (список качеств, которые вы хотите выбиратьing) и затем предоставить СУБД некоторую дополнительную информацию о том, ОТКУДА ее следует искать.
Размещение предложения WHERE в конце также имеет большой смысл:Представьте себе воронку, широкую вверху и узкую внизу.Добавляя предложение WHERE в конце оператора, вы сокращаете объем результирующих данных.Применение ограничений к вашему запросу в любом другом месте, кроме нижнего, потребует от разработчика перевернуть голову.
Предложение ORDER BY в самом конце:как только данные пройдут через воронку, отсортируйте их.
JOINS (критерии JOIN) действительно относятся к предложению FROM.
ГРУППИРОВАНИЕ:по сути, данные проходят через воронку, прежде чем они попадут в другую воронку.
Ситаксис SQL — это приятно.В этом нет ничего внутреннего.Возможно, именно поэтому SQL так популярен даже спустя столько десятилетий.Это довольно легко понять и понять.(Хотя однажды я столкнулся с 7-страничным оператором SQL (размером А4), в котором мне потребовалось немало времени, чтобы разобраться.)
Он спроектирован так, чтобы быть похожим на английский.Я думаю, что это основная причина.
Кстати, я помню, что первоначальные предварительные версии LINQ были непосредственно смоделированы по его образцу (select ... from ...).В более поздних предварительных версиях это было изменено, чтобы больше напоминать язык программирования (так что область видимости снижается).Андерс Хейлсберг особо упомянул этот странный факт о SQL (который усложняет IntelliSense и не соответствует правилам области действия C#) как причину, по которой они приняли такое решение.
В любом случае, хорошо это или плохо, но это то, что есть, и уже поздно что-либо менять.
Порядок предложений в SQL абсолютно логичен.Помните, что SQL — это декларативный язык, в котором вы заявляете, что хотите, а система сама определяет, как лучше всего это получить.Первое предложение — это предложение выбора, в котором вы перечисляете столбцы, которые вы хотите видеть в таблице результатов.Это основная цель запроса.Указав, как должен выглядеть результат, вы затем указываете, откуда должны поступать данные.Предложениеwhere ограничивает объем возвращаемых данных.Нет смысла думать о том, как ограничить ваши данные, если вы не знаете, откуда они берутся, поэтому они идут после предложения from.Предложение group by работает с операторами агрегации в предложении select и может идти куда угодно после предложения from, однако лучше подумать об агрегации отфильтрованных данных, поэтому оно должно идти после предложенияwhere.Предложение «имеющий» должно идти после предложения «группа по».Предложение order by касается того, как представляются данные, и после выбора они могут идти куда угодно.
Это соответствует остальному синтаксису 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]
Если оставить в стороне историю языка (хотя она увлекательна), я думаю, что вам не хватает того, что SQL не говорит системе, что делать, а скорее, какой конечный результат вы хотите (и он определяет, как это сделать)
фраза «подойди к той стойке, возьми шляпы с лентами, сначала синие шляпы, потом зеленые, потом красные, и принеси их мне» очень много говорит системе. как делать то, что ты хочешь.его программист думает где мы предполагаем, что рабочий очень глуп и нуждается в мельчайших подробных инструкциях.
SQL начинается с конечного результата, нужных данных, порядка столбцов и т. д.во многом это точка зрения человека, составляющего отчет.«Я хочу имя, фамилию, затем возраст, затем…» В конце концов, в этом и состоит цель запроса.Итак, все начинается с формата желаемых результатов.Затем он переходит к тому, где вы ожидаете найти данные, какие критерии искать, порядок их представления и т. д.
Таким образом, в качестве альтернативы подробному указанию того, что вы хотите от работника, SQL предполагает, что система знает, как это сделать, и больше сосредотачивается на том, что вы хотите.
Так что вместо того, чтобы педантично говорить своему работнику, чтобы он пошел сюда, возьми это, принеси туда..это больше похоже на фразу: «Мне нужны шляпы со стойки 12, у которых есть ленты, и, пожалуйста, отсортируйте их по цвету».
