Здравствуйте, Kolesiki, Вы писали:

K>Здравствуйте, netch80, Вы писали:

N>>Варианты синтаксиса, когда ключевые слова явно выделены, а идентификаторы — нет, активно пробовались ещё в середине 60-х

K>Вы не о том. В век подсветки синтаксиса прямо в редакторе, нет вообще никакой предпосылки помечать ключевые слова ещё и символами! Достаточно иметь однозначную грамматику.

Да точно! Нужно было в грамматику добавить два вида символов: цветные(нужный цвет) для ключевых слов, бесцветные — для всего остального и было бы прекрасно. Только потом на rsdn кто ни будь бы спрашивал: Почему я не могу обозвать таблицу именем из "цветных" символов?

Здравствуйте, Kolesiki, Вы писали:

K>Или (второй вариант) грамматика самого SQL настолько кривая, что ключевые слова в месте имён могут его сбить с толку?
Покажите мне здесь, где место имен, где ключевое слово:

select name, surname, from from, user

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

Здравствуйте, Kolesiki, Вы писали:

K>Что, у нас и русские вопросы теперь с трудом парсятся??
Забьем на хамство. В общем-то, оно характерно для людей, возомнивших себя гениями, видящими то, что
не видят другие (в основном из-за незнания предмета, конечно).

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

select from from from where where where is null order by union select from from group by

Здравствуйте, Kolesiki, Вы писали:

_AB>>Покажите мне здесь, где место имен, где ключевое слово:
_AB>>

_AB>>select name, surname, from from, user 
_AB>>

K>Очевидно же, что запрос кривой! Начало вот такое: "SELECT name, surname, from FROM" а дальше ошибочная запятая.
Без учета ключевых слов в качестве имен колонок, запрос абсолютно корректный.

select is_visible, is_published from sys.objects, sys.assemblies

K>Я спрашиваю, знаете ли вы из своей поверхностной практики запросы
Есть мнение, что кто-то не зная SQL, обвиняет других в поверхностной практике...

Здравствуйте, Kolesiki, Вы писали:

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

K>Ну есть у нас три from, что с того? Суньте в редактор, да посмотрите!
А запросы разве IDE парсит? Кстати, я вот "сунул в редактор" и вижу — всё синим подсвечено. Что мне делать дальше?

Да, и тут не с from надо начинать...
Для начала стоит определить сколько здесь вообще запросов. И есть ли хоть один запрос.

K>Вы (ввиду очевидного желания всех умыть) сразу неправильно ориентировали свой негатив, вместо того, чтобы уловить суть вопроса.
Какой негатив? Я начал с вежливого вопроса. В ответ получил хамство. А ожидал получить новые знания, например. Может тут гений
зашел, который покажет то, чего я не знаю. Но нет. Обычный "гений", который нифига не знает, но мнение имеет.

K>Я не утверждаю, что запросы можно писать вперемежку с любыми ключевыми словами, я лишь возмущаюсь совсем простейшим случаем с User и задаю более общий вопрос: МОЖНО ЛИ иметь SQL без ограничений на ключевые слова? Это ответ ДА или НЕТ, а не разглагольствования кто тут умнее — я или те яйцеголовые, что придумали "типа человеческий" SQL, который, к слову, НИКТО кроме программистов всё-равно не использует.
Да ну? Никто кроме программистов не использует? Т.е., те аналитики, которые сидят и вертят данные из отчетных БД, которых
я знаю, — они программисты? Администраторы баз данных — программисты?

K>Вежливость — почему бы не начать с неё?
Отличный вопрос. Советую Вам задать его самому себе прежде всего.

Здравствуйте, Kolesiki, Вы писали:

K>Собсно, сабж. Что мешает SQL'ю выполнять запросы вида
K>

K>SELECT From FROM User WHERE ...
K>

K>В MS SQL что user, что from — ключевые слова и он постоянно ругается "ошибка синтаксиса". Он что, неспособен распарсить элементарное выражение?
Да, неспособен.
Потому, что если разрешить такие имена объектов без цитирования, то непонятно, FROM — это ключевое слово или column_alias. Непонятно, where — это ключевое слово или table_alias.
Кто вам запретит написать

select user from from user

, и что это будет означать?

select [dbo].[user].[user] as [from] from [dbo].[user]

или

select [dbo].[from].[user] from [dbo].[from] as [user]

Здравствуйте, Kolesiki, Вы писали:

K>Собсно, сабж. Что мешает SQL'ю выполнять запросы вида
K>

K>SELECT From FROM User WHERE ...
K>

K>В MS SQL что user, что from — ключевые слова и он постоянно ругается "ошибка синтаксиса". Он что, неспособен распарсить элементарное выражение?
Пока не способен. Если вам легко написать такого рода парсер, обратитесь в Майрософт с предложением, может примут и внедрят в следующей версии.

Или (второй вариант) грамматика самого SQL настолько кривая, что ключевые слова в месте имён могут его сбить с толку?
Грамматика вполне нормальная. А вот поля c именами типа User и From трудно назвать нормальными, так они не несут никакого смысла. Обычно поля называеются UserId или UserNamе, а что такое просто User? Поэтому и не особо стоит тратить силы на написание парсера для полей, которые большиство толковых архитекторов никогда использовать не станут.

K>PS
K>Про квадратные скобки в курсе, но я не хочу превращать запросы в придурковатый заборчик с именами.
А вам программирование вообще как? Двойные кавычки вокруг строк, escape-последовательности? Не очень утомляет? А то может пойти куда-нить в маркетинг, где всегда человеческий язык используют?

Здравствуйте, Milena, Вы писали:

M>Здравствуйте, Kolesiki, Вы писали:

K>>Собсно, сабж. Что мешает SQL'ю выполнять запросы вида
K>>

K>>SELECT From FROM User WHERE ...
K>>

K>>В MS SQL что user, что from — ключевые слова и он постоянно ругается "ошибка синтаксиса". Он что, неспособен распарсить элементарное выражение?
M>Пока не способен. Если вам легко написать такого рода парсер, обратитесь в Майрософт с предложением, может примут и внедрят в следующей версии.

Я спрашиваю не чем мне заняться, а принципиальный вопрос синтаксиса. Вы вообще понимаете тему? Вопрос про то, можно ли в SQL обойтись БЕЗ запрета ключевых слов как имён.

M>Грамматика вполне нормальная. А вот поля c именами типа User и From трудно назвать нормальными, так они не несут никакого смысла.

Ну да, особенно User — вообще бессмыслица какая-то, да? Подумаешь, что в 99% БД это необходимая сущность!

M> Обычно поля называеются UserId

Будем учить кого и как называть? Я вообще-то и таблицу могу назвать User — именно она и фигурирует в оригинальном сообщении. Вот только использовать я её могу только через квадратные скобки.

M>А вам программирование вообще как?

Ясно. Русский быдлятник, бессмысленный и беспощадный.

Здравствуйте, vsb, Вы писали:

vsb>Например таблицу с пользователями логично называть именно user.
Таблицу с пользователями логично называть users.

vsb>И то, что это ключевое слово, меня раздражает.
То, что тебя раздражает логичность, еще ничего не означает.

vsb>В любой таблице БД лежит (или может лежать) множество записей. Нет никакой необходимости в этих ваших "-s"-ах.
Кхм... Если в коробке с носками может лежать множество носков, то ты подпишешь её "носок", а не "носки"?
Что там было о логике?

Нет, понятно, что у каждого свои предпочтения, но зачем приплетать логику туда, где её никогда не было?

Здравствуйте, _ABC_, Вы писали:

_AB>Вот это "человеческий синтаксис, который изначально задумывался"? Как будем парсить? Я имею в виду, алгоритм конкретный.
_AB>

_AB>select from from from where where where is null order by union select from from group by
_AB>

Давайте начнём с того, что не будем утрировать — я ж не предлагаю вообще сходить с ума и называть всё FROM и JOIN! Лично меня коснулась ну абсолютно дебильное ограничение, что User — это "специальное имя" и его нельзя использовать без скобок! (и по-моему Login для полей тоже)
Во-вторых, я не могу работать за компилятор и знать все немыслимые приколы, которые разрабы могут сунуть в запрос. Ну есть у нас три from, что с того? Суньте в редактор, да посмотрите!
Вы (ввиду очевидного желания всех умыть) сразу неправильно ориентировали свой негатив, вместо того, чтобы уловить суть вопроса.
Я не утверждаю, что запросы можно писать вперемежку с любыми ключевыми словами, я лишь возмущаюсь совсем простейшим случаем с User и задаю более общий вопрос: МОЖНО ЛИ иметь SQL без ограничений на ключевые слова? Это ответ ДА или НЕТ, а не разглагольствования кто тут умнее — я или те яйцеголовые, что придумали "типа человеческий" SQL, который, к слову, НИКТО кроме программистов всё-равно не использует.
И да, иногда мои решения намного умнее тех, что были придуманы 30 лет назад под реалии тех времён — это нормально. Например, я б никогда не додумался до дебилизма делать 6-символьный отступ для FORTRAN. Более современный пример — Python, который за "пробельный синтаксис" надо проклясть и сжечь.

Узнаю российский форум — никто и никогда не упустит возможность "макнуть" новичка (а может и человека намного старше и умнее вас). Вежливость — почему бы не начать с неё? Разве я своим вопросом оскорбил тут кого-то? Мы все знаем, что софт несовершенен, поэтому не вижу ничего неординарного поднять тему: это недоработка софта или это принципиальное ограничение.

Спасибо, что уделили внимание.

Здравствуйте, Kolesiki, Вы писали:

K>Я так понимаю, что вы свои очки "-9" забыли дома? Посмотрите, где у вас стоят запятые во втором запросе и где в первом!
Вопрос был такой — "как определить где находится пространство имен, а где ключевое слово".

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

Здравствуйте, Kolesiki, Вы писали:
K>Во-вторых, я не могу работать за компилятор и знать все немыслимые приколы, которые разрабы могут сунуть в запрос. Ну есть у нас три from, что с того? Суньте в редактор, да посмотрите!
Дело не в редакторе, а в неоднозначности разбора. Куда ни суй этот запрос, его можно проинтерпретировать совершенно разными способами.
Часть запросов в таком стиле можно распарсить однозначно.
Часть запросов можно распарсить однозначно только в том случае, если смотреть в метаданные.
Часть запросов можно распарсить несколькими способами.
У СУБД нет времени заниматься полным обходом всех возможных вариантов — ей запрос надо исполнять. Это в С++ компилятор может потратить 20 минут на анализ AST, пытаясь отличить declaration от usage.
А SQL надо исполнять здесь и сейчас. Поэтому приходится вводить ограничения, упрощающие парсер. В частности, лексер сразу выделяет ключевые слова, не пытаясь сначала анализировать контекст.

Здравствуйте, 0BD11A0D, Вы писали:
BDA>Оффтопик. По-моему, лучше бы сделали AS обязательным — в этом же проблема.
Это я привёл простой пример с использованием ровно тех слов, которые упомянул топикстартер.
Если мы хотим переделать грамматику, то начинается целое дерево грамматических решений. Собственно, всегда будет либо дудочка, либо кувшинчик. Либо мы делаем синтаксис более жёстким, зато разрешаем контекстные ключевые слова, либо мы делаем синтаксис помягче и поудобнее для человека, зато идентификаторы, совпадаюшие с ключевыми словами, придётся квотировать.
Авторы SQL выбрали второе решение.

Здравствуйте, Kolesiki, Вы писали:

K>Хочу человеческий синтаксис (как он и задумывался при проектировании SQL).

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

1. Интерпретатор SQL станет сложнее и медленнее. Прежде чего усложнится парсер. Если сейчас можно получить дерево выражения, а уже потом проверять что откуда брать, то при твоём подходе надо будет сразу строить догадки, а что это может быть? Более того, нельзя исключить варианты, когда интерпретатору придётся идти одновременно по нескольким возможным веткам разбора, что может дать комбинаторный взрыв вариантов, читай тормоза на ровном месте. Не говоря о том, что злоумышленник может посылать специально такие «хитрые» запросы, чтобы положить сервер. Так что потенциальная уязвимость.

2. Сообщения об ошибках потеряют ясность. Они могут выглядеть как «если рассматривать FROM как псевдоним выражения, то у нас ошибка в том, что стоит непонятная запятая. Если рассматривать FROM как ключевое слово, то...» Опять же, в случае комбинаторного взрыва сообщение может разрастись. Для разработчика это достаточно неприятно, когда непонятно что исправлять или надо тратить кучу времени на анализ сообщения об ошибке.

3. Такой подход неустойчив к опечаткам. Допустим мы два раза случайно написали FROM. В результате чего запрос остался корректным, только первый FROM начал использоваться как псевдоним. В результате чего ошибка у нас вылезет где-то далеко в коде, типа «неизвестный столбец StudentName», что несколько вводит человека в заблуждения. В результате чего разработчик может потратить кучу своего времени на поиск опечатки в имени StudentName, проверит по букве. Потом подумат, что буква «a» на самом деле кириллическая, заменит. Потом перенаберёт. Потом скопирует. Потом добавит отладочный код, который покажет ему слолбец FROM вместо ожидаемого StidentName, в результате чего он ешё раз пересмотрит тест заброса, найдёт дублирование FROM и скажет «а-а-а-а...» Ну и после того я бы зарёкся работать с такой системой.

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

Собсно, сабж. Что мешает SQL'ю выполнять запросы вида

SELECT From FROM User WHERE ...

В MS SQL что user, что from — ключевые слова и он постоянно ругается "ошибка синтаксиса". Он что, неспособен распарсить элементарное выражение? Или (второй вариант) грамматика самого SQL настолько кривая, что ключевые слова в месте имён могут его сбить с толку?
PS
Про квадратные скобки в курсе, но я не хочу превращать запросы в придурковатый заборчик с именами. Хочу человеческий синтаксис (как он и задумывался при проектировании SQL).

Здравствуйте, _ABC_, Вы писали:

_AB>Здравствуйте, Kolesiki, Вы писали:

K>>Или (второй вариант) грамматика самого SQL настолько кривая, что ключевые слова в месте имён могут его сбить с толку?
_AB>Покажите мне здесь, где место имен, где ключевое слово:
_AB>

_AB>select name, surname, from from, user 
_AB>

Очевидно же, что запрос кривой! Начало вот такое: "SELECT name, surname, from FROM" а дальше ошибочная запятая.

_AB>Если Вы считаете, что грамматика кривая, то предложите...

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

Здравствуйте, vsb, Вы писали:

vsb>Здравствуйте, Alex.Che, Вы писали:

>>> Например таблицу с пользователями логично называть именно user.

AC>>да, если пользователь один единственный.
AC>>впрочем, нужна ли в таком случае таблица...

vsb>А уж как меня раздражают таблицы, названные во множественном числе! В любой таблице БД лежит (или может лежать) множество записей. Нет никакой необходимости в этих ваших "-s"-ах.

Это часто вопрос предпочтений. Но иногда стоит просто сделать чуть иначе чем, нравится, чтобы всем было удобно работать. Сам SQL Server называет свои системные таблицы sys.columns, sys.tables etc. как раз для того, чтобы можно было писать код и со скобками, и без них.
Я вообще за гибкость. У меня на одной работе был стандарт писать ключевые слова маленькими буквами, на другой — большими. Я люблю писать большими, но если есть стандарт писать маленькими — запросто, суть-то работы не в этом, правда? И тоже самое в этими S-ами: если наличие S делает жизнь проще, почему бы нет?

Здравствуйте, netch80, Вы писали:

N>И зачем нам эти усложнённые формы?
Затем, что мы говорим о существительных, а не прилагательных?

N>Верно по обоим пунктам. Групповые существительные это crowd, flock, list, table... я об этом и говорил.
Нет, не об этом.

N>Кстати, в mysql в одноимённой базе (управляющей) названия в единственном — как то же user, или db.
Приводить mysql в пример в обсуждении правильного поведения — тот еще моветон.

Здравствуйте, netch80, Вы писали:

N>А вот на этот ответ нам сможет ответить только native English person, а не славяне, которые решают термины вкуса устриц за тех, кто их ел.
Native speakers тоже разделены на два лагеря в этом вопросе.

N>It depends.
Нет. Вопрос не религиозных заморочках, просто не та система, чтобы приводить в пример.
Это как PHP приводить в пример в обсуждении языков программирования. Слишком много отклонений
от общепринятого и слишком много разногласий даже внутри самого продукта, чтобы брать за образец.

N>пример противоположного решения — таки есть.
Примеров разных много. Сам вопрос по именованию объектов в БД религиозный во многом. И я признаю право на любую
точку зрения. Я только обратил внимание на то, что логичности в аргументах vsb не было, хотя он именно на логику
и упирал.

Здравствуйте, Milena, Вы писали:

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

Был бы я студентом, так бы и сделал! А потом начальник вместо MS SQL прикрутит какой-нибудь Оракл и что, жевать сопли "мне так Милена подсказала"? (с последущим гемороем по исправлению всех скобок на кавычки)

Здравствуйте, Kolesiki, Вы писали:

K>Был бы я студентом, так бы и сделал! А потом начальник вместо MS SQL прикрутит какой-нибудь Оракл и что, жевать сопли "мне так Милена подсказала"? (с последущим гемороем по исправлению всех скобок на кавычки)
SQL Server поддерживает ANSI SQL. Используй кавычки сразу, если есть вероятность перехода на другую СУБД.

create table "user" ("user" int)
select "user" from "user"
drop table "user"

Здравствуйте, Kolesiki, Вы писали:

K>Собсно, сабж. Что мешает SQL'ю выполнять запросы вида
K>

K>SELECT From FROM User WHERE ...
K>

K>В MS SQL что user, что from — ключевые слова и он постоянно ругается "ошибка синтаксиса". Он что, неспособен распарсить элементарное выражение?
Если в одном запросе может быть очевидно где ключевое слово, а где имя, не значит, что так же будет в других запросах.

K> Или (второй вариант) грамматика самого SQL настолько кривая, что ключевые слова в месте имён могут его сбить с толку?
Напишите свою. Вообще наверное можно ослабить это требование в языке, но только зачем? Ради различных извращений?

K>PS
K>Про квадратные скобки в курсе, но я не хочу превращать запросы в придурковатый заборчик с именами. Хочу человеческий синтаксис (как он и задумывался при проектировании SQL).
Да, sql и задумывался как человеческий язык для манипулирования данными. Были также попытки создания "человеческих" языков программирования, но все они умирали либо становились инструментом только для специалистов. Такова реальность.

Здравствуйте, Kolesiki, Вы писали:

K>Собсно, сабж. Что мешает SQL'ю выполнять запросы вида

Наличие мозгов у его авторов.

K> Он что, неспособен распарсить элементарное выражение?

Напишите тот, который способен. Дело-то несложное.

K> Хочу человеческий синтаксис
K> Хочу SELECT From FROM User

Выберите уж что-нибудь одно.

Здравствуйте, Kolesiki, Вы писали:

K>Собсно, сабж. Что мешает SQL'ю выполнять запросы вида
K>

K>SELECT From FROM User WHERE ...
K>

K>В MS SQL что user, что from — ключевые слова и он постоянно ругается "ошибка синтаксиса". Он что, неспособен распарсить элементарное выражение? Или (второй вариант) грамматика самого SQL настолько кривая, что ключевые слова в месте имён могут его сбить с толку?
K>PS
K>Про квадратные скобки в курсе, но я не хочу превращать запросы в придурковатый заборчик с именами. Хочу человеческий синтаксис (как он и задумывался при проектировании SQL).

Варианты синтаксиса, когда ключевые слова явно выделены, а идентификаторы — нет, активно пробовались ещё в середине 60-х, получалось что-то вроде

  'if' x > y 'then'
    max := x
  'else'
    max := y
  'end' 'if'

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

Только в C# (из мейнстримных) ввели универсальный суффикс "это не ключевое слово" в виде символа @, хотя я бы взял что-то за пределами ascii — например, ¤.
И, наоборот, отдельный набор слов, которые работают как ключевые только со спец-префиксом, можно §.

Здравствуйте, Qulac, Вы писали:

K>>В MS SQL что user, что from — ключевые слова и он постоянно ругается "ошибка синтаксиса". Он что, неспособен распарсить элементарное выражение?
Q>Если в одном запросе может быть очевидно где ключевое слово, а где имя, не значит, что так же будет в других запросах.

Это замечание мне никак не помогает. Мне нужен либо конкретный пример, где вообще никак нельзя разрулить запрос без занесения имени в скобки, либо объяснение, нафига ключевые слова запрещены.

K>> Или (второй вариант) грамматика самого SQL настолько кривая, что ключевые слова в месте имён могут его сбить с толку?
Q>Напишите свою. Вообще наверное можно ослабить это требование в языке, но только зачем? Ради различных извращений?

О, да! Захотел назвать таблицу пользователей User — каков грязный ублюдок! (50 оттенков программиста)

В общем, пока по существу — ничего.

Здравствуйте, netch80, Вы писали:

N>Варианты синтаксиса, когда ключевые слова явно выделены, а идентификаторы — нет, активно пробовались ещё в середине 60-х

Вы не о том. В век подсветки синтаксиса прямо в редакторе, нет вообще никакой предпосылки помечать ключевые слова ещё и символами! Достаточно иметь однозначную грамматику.

Здравствуйте, Kolesiki, Вы писали:

N>>Варианты синтаксиса, когда ключевые слова явно выделены, а идентификаторы — нет, активно пробовались ещё в середине 60-х

K>Вы не о том. В век подсветки синтаксиса прямо в редакторе, нет вообще никакой предпосылки помечать ключевые слова ещё и символами! Достаточно иметь однозначную грамматику.

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

Здравствуйте, Kolesiki, Вы писали:

_AB>>Покажите мне здесь, где место имен, где ключевое слово:
_AB>>select name, surname, from from, user

K>Очевидно же, что запрос кривой! Начало вот такое: "SELECT name, surname, from FROM" а дальше ошибочная запятая.

Очевидно же, что вы ошибаетесь. Второе from это назначение алиаса для колонки результата.

Здравствуйте, netch80, Вы писали:

N>Очевидно же, что вы ошибаетесь.
Человек не знает о возможности использовать запятые в джойнах.

Здравствуйте, Kolesiki, Вы писали:

K>Про квадратные скобки в курсе, но я не хочу превращать запросы в придурковатый заборчик с именами. Хочу человеческий синтаксис (как он и задумывался при проектировании SQL).

Нужно быть очень большим извращенцем, чтобы давать имена совпадающие с ключевыми словами. Относится к любому языку. В том числе и не компьютерному.

Здравствуйте, alpha21264, Вы писали:

A>Нужно быть очень большим извращенцем, чтобы давать имена совпадающие с ключевыми словами. Относится к любому языку. В том числе и не компьютерному.

На следующий день вдруг введут в язык новое ключевое слово, и оно совпадёт с твоим названием переменной.
Например, category. И что, от этого ты мгновенно станешь извращенцем? Ну, впрочем, наверно, станешь, раз так настаиваешь

А у нормальных языков есть средства описать, что какой-то идентификатор — гарантированно не ключевое слово, даже если совпало.
Жаль, что среди языков программирования таких мало — C# (префикс — @class), Erlang (синтаксис квотинга атома — 'if' вместо if)...
Надеюсь, скоро таких будет больше.

Здравствуйте, netch80, Вы писали:

N>А у нормальных языков есть средства описать, что какой-то идентификатор — гарантированно не ключевое слово, даже если совпало.
У SQL тоже есть, только ТС они не устраивают.

Здравствуйте, Kolesiki, Вы писали:

K>Здравствуйте, Milena, Вы писали:

M>>Здравствуйте, Kolesiki, Вы писали:

K>>>Собсно, сабж. Что мешает SQL'ю выполнять запросы вида
K>>>

K>>>SELECT From FROM User WHERE ...
K>>>

K>>>В MS SQL что user, что from — ключевые слова и он постоянно ругается "ошибка синтаксиса". Он что, неспособен распарсить элементарное выражение?
M>>Пока не способен. Если вам легко написать такого рода парсер, обратитесь в Майрософт с предложением, может примут и внедрят в следующей версии.

K>Я спрашиваю не чем мне заняться, а принципиальный вопрос синтаксиса. Вы вообще понимаете тему? Вопрос про то, можно ли в SQL обойтись БЕЗ запрета ключевых слов как имён.
Я ответила на ваш вопрос — смотрите выше жирным. Ключевое слово тут "Пока", хотя я сильно сомневаюсь в необходимость вкладывать сотни человекочасов в то, что нужно единицам.

M>>Грамматика вполне нормальная. А вот поля c именами типа User и From трудно назвать нормальными, так они не несут никакого смысла.
K>Ну да, особенно User — вообще бессмыслица какая-то, да? Подумаешь, что в 99% БД это необходимая сущность!
Ну как сказать. У меня и в прошлой компании, и в этой таблица такого типа называется Users — о боже, и как-то нам даже не приходится квадратные скобки писать!

M>> Обычно поля называеются UserId
K>Будем учить кого и как называть? Я вообще-то и таблицу могу назвать User — именно она и фигурирует в оригинальном сообщении. Вот только использовать я её могу только через квадратные скобки.
Забавно, что вы готовы истратить огромное количество времени на страдания о том, как трудно писать код с квадратными скобками и какой он нечеловеческий, хотя за это время можно было эти самые скобки везде проставить и жить счастливо. Будьте проще — есть то, что есть. 10-15 лет назад был SQL Server 2000, который не поддерживал IntelliSense, хотя в ORACLE это все работало без проблем, а теперь SQL позволяет писать даже запросы к Hadoop. Так не забить ли на эту мелочь с синтаксисом и не переключиться ли на решение реальных проблем вместо борьбы с квадратными скобками?

Здравствуйте, Milena, Вы писали:

M>Грамматика вполне нормальная. А вот поля c именами типа User и From трудно назвать нормальными, так они не несут никакого смысла. Обычно поля называеются UserId или UserNamе, а что такое просто User? Поэтому и не особо стоит тратить силы на написание парсера для полей, которые большиство толковых архитекторов никогда использовать не станут.

Например таблицу с пользователями логично называть именно user. И то, что это ключевое слово, меня раздражает.

> Например таблицу с пользователями логично называть именно user.

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

Здравствуйте, Alex.Che, Вы писали:

>> Например таблицу с пользователями логично называть именно user.

AC>да, если пользователь один единственный.
AC>впрочем, нужна ли в таком случае таблица...

А уж как меня раздражают таблицы, названные во множественном числе! В любой таблице БД лежит (или может лежать) множество записей. Нет никакой необходимости в этих ваших "-s"-ах.

Здравствуйте, Milena, Вы писали

M>Это часто вопрос предпочтений. Но иногда стоит просто сделать чуть иначе чем, нравится, чтобы всем было удобно работать. Сам SQL Server называет свои системные таблицы sys.columns, sys.tables etc. как раз для того, чтобы можно было писать код и со скобками, и без них.
M>Я вообще за гибкость. У меня на одной работе был стандарт писать ключевые слова маленькими буквами, на другой — большими. Я люблю писать большими, но если есть стандарт писать маленькими — запросто, суть-то работы не в этом, правда? И тоже самое в этими S-ами: если наличие S делает жизнь проще, почему бы нет?

Смотря чем этот стандарт обоснован. Если уже весь проект так написан, это одно. А если из-за того, что слово user ключевое — я скорее эти самые скобки поставлю или account назову.

Здравствуйте, _ABC_, Вы писали:

vsb>>В любой таблице БД лежит (или может лежать) множество записей. Нет никакой необходимости в этих ваших "-s"-ах.
_AB>Кхм... Если в коробке с носками может лежать множество носков, то ты подпишешь её "носок", а не "носки"?
_AB>Что там было о логике?

В английском нормой является использование единственного числа перед групповыми существительными.
Field list, а не fields list. User table, а не users table. Более того, последнее путается устно с user's table (таблица конкретного пользователя).
Поэтому твоё утверждение про логику, как минимум, не пригодно для общего случая.

В других языках это ещё шире — например, в тюркских с числительными используется единственное — дом это ev, дома́ это evler, два это iki, а два дома — iki ev, а не iki evler.

_AB>Нет, понятно, что у каждого свои предпочтения, но зачем приплетать логику туда, где её никогда не было?

Была и есть. Просто надо выйти за пределы родного языка (и вспомнить, что в IT основной — английский).

Здравствуйте, _ABC_, Вы писали:

vsb>>Например таблицу с пользователями логично называть именно user.
_AB>Таблицу с пользователями логично называть users.

Нет, её логично называть user.

vsb>>И то, что это ключевое слово, меня раздражает.
_AB>То, что тебя раздражает логичность, еще ничего не означает.

В этом нет ничего логичного.

vsb>>В любой таблице БД лежит (или может лежать) множество записей. Нет никакой необходимости в этих ваших "-s"-ах.
_AB>Кхм... Если в коробке с носками может лежать множество носков, то ты подпишешь её "носок", а не "носки"?
_AB>Что там было о логике?

Название таблицы это не название коробки. Это идентификатор, ассоциированный с отношением. Отношение "пользователь", а не "пользователи".

Здравствуйте, netch80, Вы писали:

N>В английском нормой является использование единственного числа перед групповыми существительными.
N>Field list, а не fields list. User table, а не users table.
Или a list of fields and a list of users...

Кстати, в словосочетании field list, слово field выступает в качестве прилагательного. А групповые
существительные — это, вообще-то, совершенно другое.

Здравствуйте, vsb, Вы писали:

vsb>Нет, её логично называть user.
Не логичнее, чем users.

vsb>В этом нет ничего логичного.
В твоем раздражении? Полностью согласен.

vsb>Название таблицы это не название коробки.
Вот. Наконец-то мы начинаем подходить к логике.
У обоих подходов есть свои логичные аргументы. Но ты не привел их. Ты просто
высказал безапелляционное мнение, ничем его не подтвердив.

Здравствуйте, _ABC_, Вы писали:

N>>В английском нормой является использование единственного числа перед групповыми существительными.
N>>Field list, а не fields list. User table, а не users table.
_AB>Или a list of fields and a list of users...

И зачем нам эти усложнённые формы?

_AB>Кстати, в словосочетании field list, слово field выступает в качестве прилагательного. А групповые
_AB>существительные — это, вообще-то, совершенно другое.

Верно по обоим пунктам. Групповые существительные это crowd, flock, list, table... я об этом и говорил.

Кстати, в mysql в одноимённой базе (управляющей) названия в единственном — как то же user, или db.

Здравствуйте, netch80, Вы писали:

N>Здравствуйте, alpha21264, Вы писали:

A>>Нужно быть очень большим извращенцем, чтобы давать имена совпадающие с ключевыми словами. Относится к любому языку. В том числе и не компьютерному.

N>На следующий день вдруг введут в язык новое ключевое слово, и оно совпадёт с твоим названием переменной.
N>Например, category. И что, от этого ты мгновенно станешь извращенцем? Ну, впрочем, наверно, станешь, раз так настаиваешь

1) От этого язык станет другим.
2) При следующей компиляции я переобзову переменную. (а вообще, я пишу переменные по русски).

Здравствуйте, _ABC_, Вы писали:

_AB>Здравствуйте, netch80, Вы писали:

N>>И зачем нам эти усложнённые формы?
_AB>Затем, что мы говорим о существительных, а не прилагательных?

А вот на этот ответ нам сможет ответить только native English person, а не славяне, которые решают термины вкуса устриц за тех, кто их ел.

N>>Кстати, в mysql в одноимённой базе (управляющей) названия в единственном — как то же user, или db.
_AB>Приводить mysql в пример в обсуждении правильного поведения — тот еще моветон.

It depends. Какие бы ни были у тебя религиозные заморочки в области практической применимости его к твоим задачам, к терминологии это не относится, а вот пример противоположного решения — таки есть.

Здравствуйте, alpha21264, Вы писали:

A>>>Нужно быть очень большим извращенцем, чтобы давать имена совпадающие с ключевыми словами. Относится к любому языку. В том числе и не компьютерному.

N>>На следующий день вдруг введут в язык новое ключевое слово, и оно совпадёт с твоим названием переменной.
N>>Например, category. И что, от этого ты мгновенно станешь извращенцем? Ну, впрочем, наверно, станешь, раз так настаиваешь

A>1) От этого язык станет другим.

Формальности.

A>2) При следующей компиляции я переобзову переменную. (а вообще, я пишу переменные по русски).

schotchik_bajtov?

Здравствуйте, _ABC_, Вы писали:

_AB>Здравствуйте, Kolesiki, Вы писали:

_AB>>>Покажите мне здесь, где место имен, где ключевое слово:
_AB>>>

_AB>>>select name, surname, from from, user 
_AB>>>

K>>Очевидно же, что запрос кривой! Начало вот такое: "SELECT name, surname, from FROM" а дальше ошибочная запятая.
_AB>Без учета ключевых слов в качестве имен колонок, запрос абсолютно корректный.
_AB>

_AB>select is_visible, is_published from sys.objects, sys.assemblies

Я так понимаю, что вы свои очки "-9" забыли дома? Посмотрите, где у вас стоят запятые во втором запросе и где в первом!


_AB>Есть мнение, что кто-то не зная SQL, обвиняет других в поверхностной практике...

Есть мнение, что пижонам не нужно даже читать вопросы вопрошающего — надо сразу влезть с компетентным мнением и отвечать о чём-то своём, абстрактном.
Повторяю вопрос как в яслях: ЕСТЬ ИЛИ НЕТ какие-то SQL запросы, где ключевые слова в качестве имён таблиц/полей могут привести к неоднозначному парсингу?

Здравствуйте, netch80, Вы писали:

_AB>>>select name, surname, from from, user

K>>Очевидно же, что запрос кривой! Начало вот такое: "SELECT name, surname, from FROM" а дальше ошибочная запятая.

N>Очевидно же, что вы ошибаетесь. Второе from это назначение алиаса для колонки результата.

Я ж не компьютер, могу что-то упустить. Но что от этого поменялось-то?? Ну значит у нас SELECT и список колонок с синонимами! Что тут криминального? Редактор же всё-равно подсветит где у вас что, так что этот кусок кода ровным счётом никак не отвечает на поставленный вопрос:

Мне нужен либо конкретный пример, где вообще никак нельзя разрулить запрос без занесения имени в скобки, либо объяснение, нафига ключевые слова запрещены.

Здравствуйте, Alex.Che, Вы писали:

>> Например таблицу с пользователями логично называть именно user.

AC>да, если пользователь один единственный.
AC>впрочем, нужна ли в таком случае таблица...

Не смешно и в принципе нет никакого правила почему мы должны использовать множественное число. Достаточно посмотреть на это:

SELECT User.Name

Здесь я хочу запросить имя юзера, а не юзерОВ. Потому что это запрос как бы в контексте каждой записи. Это вдвойне имеет смысл, когда начинаешь джойнить: User.ID = CreatorID — это совпадение ОДНОГО юзера с чужим полем.

Здравствуйте, _ABC_, Вы писали:

_AB>Здравствуйте, vsb, Вы писали:

vsb>>Например таблицу с пользователями логично называть именно user.
_AB>Таблицу с пользователями логично называть users.

Если ты пишешь стихи, а не программы — тогда да. Но когда в JOIN'е идёт условие, оно выглядит примерно так: User.ID = Purchase.CustomerID — это условие совпадения ОДНОЙ записи.
Да и вообще, МНОЖЕСТВО записей вовсе не означает работу с множеством — как раз наоборот, в работе мы часто обрабатываем ОДНУ запись из запрошенного массива.


vsb>>В любой таблице БД лежит (или может лежать) множество записей. Нет никакой необходимости в этих ваших "-s"-ах.
_AB>Кхм... Если в коробке с носками может лежать множество носков, то ты подпишешь её "носок", а не "носки"?

А если у тебя попросили зелёный носок, тебя просят "дай мне зелёный НОСКИ"? В select'е то же самое: дай мне User, где его ID = 2. К чему там s??

vsb>>>Например таблицу с пользователями логично называть именно user.
_AB>>Таблицу с пользователями логично называть users.
K>Если ты пишешь стихи, а не программы — тогда да. Но когда в JOIN'е идёт условие, оно выглядит примерно так: User.ID = Purchase.CustomerID — это условие совпадения ОДНОЙ записи.
K>Да и вообще, МНОЖЕСТВО записей вовсе не означает работу с множеством — как раз наоборот, в работе мы часто обрабатываем ОДНУ запись из запрошенного массива.

Не хочу сказать, что мое мнение есть истина в последней инстанции, но считаю, что некорректный пример. Условие в join как раз корректнее во множественном числе
Users.ID = Purchase.CustomerID — это id покупателя совпадает с id из таблицы пользователей.
Т.е. на мой взгляд логичнее отделять название таблицы от названия одной ее конкретной записи.

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

K>Я не утверждаю, что запросы можно писать вперемежку с любыми ключевыми словами, я лишь возмущаюсь совсем простейшим случаем с User и задаю более общий вопрос: МОЖНО ЛИ иметь SQL без ограничений на ключевые слова? Это ответ ДА или НЕТ, а не разглагольствования кто тут умнее — я или те яйцеголовые, что придумали "типа человеческий" SQL, который, к слову, НИКТО кроме программистов всё-равно не использует.
K>И да, иногда мои решения намного умнее тех, что были придуманы 30 лет назад под реалии тех времён — это нормально. Например, я б никогда не додумался до дебилизма делать 6-символьный отступ для FORTRAN. Более современный пример — Python, который за "пробельный синтаксис" надо проклясть и сжечь.
K>Узнаю российский форум — никто и никогда не упустит возможность "макнуть" новичка (а может и человека намного старше и умнее вас). Вежливость — почему бы не начать с неё? Разве я своим вопросом оскорбил тут кого-то? Мы все знаем, что софт несовершенен, поэтому не вижу ничего неординарного поднять тему: это недоработка софта или это принципиальное ограничение.

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

Здравствуйте, Kolesiki, Вы писали:

K>И да, иногда мои решения намного умнее тех, что были придуманы 30 лет назад под реалии тех времён — это нормально. Например, я б никогда не додумался до дебилизма делать 6-символьный отступ для FORTRAN.

Это было отличное решение для технического уровня 50-х.

K> Более современный пример — Python, который за "пробельный синтаксис" надо проклясть и сжечь.

А это — отличное решение и сейчас. Например, такая группировка отступами дала совершенно естественный путь расширения управляющих конструкций без необходимости их полной переделки: добавление else во while или try — возможность, которая используется не так часто, но при необходимости её использования даёт очень красивый код.
На C с потомками ты такого не сделаешь.

K>Узнаю российский форум — никто и никогда не упустит возможность "макнуть" новичка

Который начал всё с яростных нападок — ничего удивительного.

K> (а может и человека намного старше и умнее вас). Вежливость — почему бы не начать с неё?

Начни. С извинений за свои "проклясть и сжечь".

Здравствуйте, Kolesiki, Вы писали:

K>Я так понимаю, что вы свои очки "-9" забыли дома?
...
K>Есть мнение, что пижонам не нужно даже читать вопросы вопрошающего — надо сразу влезть с компетентным мнением и отвечать о чём-то своём, абстрактном.
...
K>Повторяю вопрос как в яслях:

Кто-то рядом вспоминал о вежливости?

Здравствуйте, Kolesiki, Вы писали:

K>>>Очевидно же, что запрос кривой! Начало вот такое: "SELECT name, surname, from FROM" а дальше ошибочная запятая.
N>>Очевидно же, что вы ошибаетесь. Второе from это назначение алиаса для колонки результата.
K>Я ж не компьютер, могу что-то упустить.

О! Вот теперь вдумайтесь в эту фразу.

K> Но что от этого поменялось-то?? Ну значит у нас SELECT и список колонок с синонимами! Что тут криминального? Редактор же всё-равно подсветит где у вас что, так что этот кусок кода ровным счётом никак не отвечает на поставленный вопрос:
K>

K>Мне нужен либо конкретный пример, где вообще никак нельзя разрулить запрос без занесения имени в скобки, либо объяснение, нафига ключевые слова запрещены.

Ну, сейчас после всех ваших выпадов вряд ли кто-то будет стараться подобрать или найти такой пример. Я уверен, что примеры есть, и языковые гуру его знают, но тут вряд ли присутствуют участники комитета SQL.
Но я рекомендую ещё раз вдуматься, что я говорил: опыт языков без ключевых слов уже есть, и его не хотят повторять. Одна только история с Фортраном и DO достаточна, чтобы все чувствовали себя обжёгшимися (даже если на Фортране не писали) и дули на воду.

Попробуйте подождать пару месяцев и спросить без наездов, возможно, кто-то и найдёт пример.

Здравствуйте, Kolesiki, Вы писали:

K>Если ты пишешь стихи, а не программы — тогда да. Но когда в JOIN'е идёт условие, оно выглядит примерно так: User.ID = Purchase.CustomerID — это условие совпадения ОДНОЙ записи.
Нет. Не одной. Кстати, у тебя пользователи всегда совершают только одну покупку?

K>Да и вообще, МНОЖЕСТВО записей вовсе не означает работу с множеством — как раз наоборот, в работе мы часто обрабатываем ОДНУ запись из запрошенного массива.
Как раз наоборот. Редко мы так делаем. Ну, если речь не о наколенной поделке, конечно.


K>А если у тебя попросили зелёный носок, тебя просят "дай мне зелёный НОСКИ"? В select'е то же самое: дай мне User, где его ID = 2. К чему там s??
В запросе будет "выбери то-то из пользователей тех/того, у кого ID = 2".
Или "выбери такие-то поля из таблицы пользователей, у кого имя равно колесики".
Абсолютно корректная фраза как с точки зрения русского, так и английского языков.

Здравствуйте, Sinclair, Вы писали:

S>Кто вам запретит написать
S>

S>select user from from user
S>

S>, и что это будет означать?
S>

S>select [dbo].[user].[user] as [from] from [dbo].[user]
S>

S>или
S>

S>select [dbo].[from].[user] from [dbo].[from] as [user]
S>

Оффтопик. По-моему, лучше бы сделали AS обязательным — в этом же проблема.

K>Я так понимаю, что вы свои очки "-9" забыли дома? Посмотрите, где у вас стоят запятые во втором запросе и где в первом!



Сдается мне, джентльмены, что это была комедия По-моему, это стеб какой-то.

Здравствуйте, Kolesiki, Вы писали:

K>Собсно, сабж. Что мешает SQL'ю выполнять запросы вида
K>

K>SELECT From FROM User WHERE ...
K>

Гмм.

SELECT AND.SELECT FROM WHERE AS AND WHERE WHERE.SELECT == WHERE.WHERE

Ой, да ну нафик.