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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Здравствуйте, _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) При следующей компиляции я переобзову переменную. (а вообще, я пишу переменные по русски).

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

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

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

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

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

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

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

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

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

Здравствуйте, _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 и список колонок с синонимами! Что тут криминального? Редактор же всё-равно подсветит где у вас что, так что этот кусок кода ровным счётом никак не отвечает на поставленный вопрос:

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

Здравствуйте, _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, который за "пробельный синтаксис" надо проклясть и сжечь.

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

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

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

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

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