Почему я должен использовать ключевые слова SQL?

Ответ 1

Я думаю, что последнее более читаемо. Вы можете легко отделить ключевые слова от имен таблиц и столбцов и т.д.

Ответ 2

Я согласен с вами - для меня, в верхнем регистре просто ОТКРОЙТЕ.

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

Я не знаю об исторической причине, но теперь это просто субъективное предпочтение.

Изменить, чтобы уточнить мои рассуждения:

Не могли бы вы загладить свои ключевые слова на любом другом современном языке? Пример:

USING (EditForm form = NEW EditForm()) {
    IF (form.ShowDialog() == DialogResult.OK) {
       IF ( form.EditedThing == null ) {
          THROW NEW Exception("No thing!");
       }
       RETURN form.EditedThing;
    } ELSE {
       RETURN null;
    }
}              

Тьфу!

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

Ответ 3

Одна вещь, которую я добавлю к этому, я еще не видел, чтобы кто-нибудь воспитывал:

Если вы используете ad hoc SQL с языка программирования, у вас будет много SQL внутри строк. Например:

insertStatement = "INSERT INTO Customers (FirstName, LastName) VALUES ('Jane','Smith')"

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

Ответ 4

От Джо Селко "Стиль программирования SQL" (ISBN 978-0120887972):

Правило:

Прописьте зарезервированные слова.

Обоснование:

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

Типографы используют термин bouma for форма слова. Термин появляется в книге Павла Саенгера (1975). Представить каждая буква на прямоугольной карте, которая просто подходит, чтобы вы видели восходящие, спусковые и базовые буквы как различные "блоки Лего", которые скрепляются друг с другом, чтобы сделать слово.

Бума слова верхнего регистра всегда простой, плотный прямоугольник и легко выбрать из поля строчные слова.

Я считаю, что это единственная книга о эвристике SQL, написанная известным автором SQL-работ. Так это абсолютная правда? Кто знает. Это звучит достаточно разумно, и я могу хотя бы указать правило члену команды и сказать им следовать за ним (и если они хотят обвинить кого-то, кого я даю им адрес электронной почты Celko:)

Ответ 5

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

Ответ 6

В коде есть знаки препинания, которые отсутствуют в SQL-запросах. Есть точки и круглые скобки и точки с запятой, которые помогут вам сохранить ситуацию в отдельности. Код также имеет строки. Несмотря на то, что вы можете написать инструкцию SQL на нескольких физических линиях, это один оператор, одна "строка кода".

ЕСЛИ я должен был писать текст на английском без какой-либо обычной пунктуации, может быть, это было бы легче, если бы я опустил начало новых предложений. Так что было бы легче сказать, где кто-то закончил, а затем начал Иное, блок текста, который долгое время вероятно, будет очень трудно прочитать NOT, что id предлагает его легко читать сейчас, НО по крайней мере вы можете следовать за ним, я думаю,

Ответ 7

Я предпочитаю ключевые слова в нижнем регистре. Цвет студия Management Studio кодирует ключевые слова, поэтому нет проблем с их отличием от идентификаторов.

И ключевые слова в верхнем регистре чувствуют себя так... хорошо... BASIC...;)

- "BASIC, COBOL и FORTRAN призвали с восьмидесятых годов, они хотели, чтобы их ВЕРХНИЙ КЛЮЧЕВЫЕ СЛОВА".;)

Ответ 8

Мне нравится использовать верхний регистр по ключевым словам SQL. Я думаю, что мой ум проскакивает над ними, поскольку они действительно блокированы и концентрируются на том, что важно. Блочные слова разделяли важные биты при компоновке следующим образом:

SELECT
  s.name,
  m.eyes,
  m.foo
FROM
  muppets m,
  muppet_shows ms,
  shows s
WHERE
  m.name = 'Gonzo' AND
  m.muppetId = ms.muppetId AND
  ms.showId = s.showId

(Отсутствие объединения ANSI является проблемой для другого вопроса.)

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

Ответ 9

Это просто вопрос удобочитаемости. Помогает вам быстро различать ключевые слова SQL.

Btw, на этот вопрос уже был дан ответ: Является ли регистр синтаксиса SQL чувствительным?

Ответ 10

Это просто вопрос читаемости. Использование UPPERCASE для SQL-запросов помогает сделать script более понятным.

Ответ 11

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

Я считаю, что строчные буквы легче читать и что, учитывая, что ключевые слова sql выделяются синим цветом в любом случае.

В дни славы ключевые слова были в плену, потому что мы разрабатывали на зеленых экранах!

Вопрос: если мы не пишем ключевые слова С# в верхнем регистре, то зачем мне писать слова sql в верхнем регистре?

Как и кто-то еще сказал, что столики - СЛОВА!

Ответ 12

Я предпочитаю использовать верхний регистр для ключевых слов в SQL.

Да, нижний регистр более читабельен, но для меня потребуется дополнительная секунда для сканирования по запросу, который будет полезен вам большую часть времени. После того, как это будет сделано и протестировано, вы никогда не увидите его снова (DAL, хранимый proc или что-то, что скроет его от вас).

Если вы читаете его впервые, заглавные буквы WHERE AND JOIN будут прыгать прямо на вас, как и должно быть.

Ответ 13

В 80-х годах я использовал для заполнения имен баз данных и оставлял ключевые слова sql в нижнем регистре. Большинство авторов делали наоборот, используя ключевые слова SQL. В конце концов, я начал собираться вместе с толпой.

Проще говоря, я упомянул, что в большинстве опубликованных фрагментов кода на C, С++ или Java языковые ключевые слова всегда в нижнем регистре, а ключевые слова в верхнем регистре могут даже не распознаваться как таковые некоторыми синтаксическими анализаторами. Я не вижу веской причины использовать противоположное соглашение в SQL, которое вы используете на языке программирования, даже когда SQL встроен в исходный код.

И я не защищаю использование всех кепок для имен баз данных. Это на самом деле немного похоже на "крик". И есть более эффективные соглашения, например, использование нескольких букв верхнего регистра в именах баз данных. (Под "именами баз данных" я имею в виду имена схем, объектов схемы, таких как таблицы, и, возможно, несколько других вещей.) Просто потому, что я сделал это в 80-х, это не значит, что я должен защищать его сегодня.

Наконец, "De gustibus non dissandum est".

Ответ 14

Некоторые разработчики SQL здесь любят описывать это следующим образом:

SELECT s.name, m.eyes, m.foo
FROM muppets m, muppet_shows ms, shows s 
WHERE m.name = 'Gonzo' AND m.muppetId = ms.muppetId AND ms.showId = s.showId

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

Ответ 15

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

Еще одно преимущество заключается в том, что я могу оставить код как есть и напечатать его в традиционном стиле. (Я использую пакет listings в LaTeX для довольно печатного кода.)

Ответ 16

Я использую SQL, чтобы сделать его более "контрастным" для основного языка (в основном С# в наши дни).

Это просто вопрос предпочтения и/или традиции действительно...