Здравствуйте, 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".
Или "выбери такие-то поля из таблицы пользователей, у кого имя равно колесики".
Абсолютно корректная фраза как с точки зрения русского, так и английского языков.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, 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]

Здравствуйте, 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 обязательным — в этом же проблема.

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

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

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

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

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

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

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

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

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

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