AkinanrmBeginnerА можно по подробней о минусах
Ни один SQL-сервер не обладает телепатическими способностями. Любая потенциальная неоднозначность должна быть устранена.

В запросе более 1 таблицы? ОБЯЗАТЕЛЬНЫ алиасы таблиц для КАЖДОГО поля - и неважно, что имя не дублируется. Причём алиасы ОБЯЗАНЫ иметь уникальное полное имя в пределах текста запроса.

Последнее условие у тебя не было выполнено.

AkinanrmBeginnerА можно по подробней о минусах
Ни один SQL-сервер не обладает телепатическими способностями. Любая потенциальная неоднозначность должна быть устранена.

В запросе более 1 таблицы? ОБЯЗАТЕЛЬНЫ алиасы таблиц для КАЖДОГО поля - и неважно, что имя не дублируется.В общем случае - неверное утверждение.
Алиасы нужны только тогда, когда имена полей в разных участвующих в запросе таблицах одинаковы. И только тогда, когда это неоднозначное имя используется в результате выборки.
AkinaПричём алиасы ОБЯЗАНЫ иметь уникальное полное имя в пределах текста запроса.

Последнее условие у тебя не было выполнено.

Akinasphinx_mvАлиасы нужны только тогда, когда имена полей в разных участвующих в запросе таблицах одинаковы.
Вопрос темы - прекрасное опровержение этого утверждения.Нет никакого опровержения темы - есть указание на конкретное неправильное Ваше утверждение ВНУТРИ темы:
AkinaОБЯЗАТЕЛЬНЫ алиасы таблиц для КАЖДОГО поля - и неважно, что имя не дублируется
Ваша "обязательность" использования алиасов в запросах - это Вы откуда-то выдумали.
И синтаксис вида "таблица.поле" (в данном конкретном случае "tab1.c") к алиасам не имеет никакого отношения.

Алисы (для таблиц, их полей и полей результата запроса) совершенно НЕ требуются, если НЕТ неоднозначности при использовании таблиц/представлений и их полей в запросе. И тема, кстати, вызвана именно НЕОДНОЗНАЧНЫМ использованием полей из таблиц и результата запроса.

ZyK_BotaNsphinx_mvАлиасы нужны только тогда, когда имена полей в разных участвующих в запросе таблицах одинаковы.
не путать формальные правила языка скл, и правила написания кода принятые программистами.
ОБЯЗАТЕЛЬНО ПУТАТЬ!!!
Потому как запрос должен соответствовать стандартам, синтаксису и правилам построения запросов для конкретной платформы, а не идеям об "обязательности" от отдельно взятых программистов.
ZyK_BotaNАкина прав, если больше 1-й таблицы, везде нужно обращаться к полям через ими таблицы или ее алиаса.
Акина НЕ прав - он утверждает об ОБЯЗАТЕЛЬНОСТИ АЛИАСОВ, что "в общем случае" противоречит даже возможности использования имени таблицы при обращении к полю... Алиас таблицы - опциональная альтернатива имени талицы.

Akinasphinx_mvАкина НЕ прав - он утверждает об ОБЯЗАТЕЛЬНОСТИ АЛИАСОВ
Смотрим в книгу, видим фигу?
AkinaОБЯЗАТЕЛЬНЫ алиасы таблиц для КАЖДОГО поля
То, что подчёркнуто - нельзя выбрасывать из фразы. Иначе действительно получается бред.
Выбрасывай, не выбрасывай - смысл фразы НЕ меняется: НЕТ никакой "обязательности" в использовании алиасов . То есть - вообще...
В лучшем случае, есть рекомендации их использовать - и не более того.
AkinaЕсли перевести - везде, где указано имя поля, обязательно следует к нему добавлять алиас (если алиас для имени явно не задан - его роль выполняет само имя) таблицы.
А если ЕЩЕ раз "перечитать" и "перевести"? Еще и с документацией свериться не мешало бы...
"Имя" таблицы и "алиас" таблицы - разные вещи.
Если Вы "обязаны везде использовать алиасы" - Вы "не имеете права" использовать имя таблицы.
"Обязательность" исключает другие "возможности".
AkinaДобавлю - если есть потенция, пусть и мизерная, и в далёком будущем, работы с несколькими БД - то следует добавлять ещё и имя базы данных.Вы забыли про схему или владельца таблицы/представления...
Ну, а возможность работы с несколькими базами данных (в том числе на разных серверах баз данных от разных производителей), которые Вы "теоретически" получите в "далеком будущем", на практике ОЧЕНЬ давно (и весьма широко) применяется...
AkinaСтандарт SQL этого, действительно, не требует..Все, что не соответствует требованиям стандартов и разумным соображениям - фтопку.
AkinaЭто - best practice."Best practice" - это РЕКОМЕНДАЦИИ, а не ОБЯЗАННОСТЬ делать именно так.
Алиасы - это, в лучшем случае, способ сократить именование полностью квалифицированного имени объекта (таблицы/представления или их полей) в запросах. И их использование НЕ обязательно.
AkinaНесоблюдение которого сплошь и рядом порождает грабли различной длины и ширины - особенно на этапах доработки и модификации по итогам определённого периода эксплуатации и/или вследствие изменения внешних условий (законодательства, требований и пр.).Пофиг!
Если при разборе текста запроса программист может сделать ошибку вследствие недостаточной квалификации, незнания точной структуры и возможных и допустимых связей между данными или вследствие очевидной сложности запроса, ошибку он все равно допустит.
Алиасы НЕ панацея. Если в запросе МОЖНО их не использовать, их НЕ используют.
И никакой "обязательности" - в отличие от рекомендаций.
AkinaЗакладывание подобной "дуракоустойчивости" я лично считаю ОБЯЗАТЕЛЬНОЙ составляющей. И очень жаль, что она не прописана в стандарте.В таких случаях рекомендуется писать, что это ВАША собственная "обязательность" и не требовать этой обязательности от других.

ZyK_BotaNsphinx_mvпропущено...
ОБЯЗАТЕЛЬНО ПУТАТЬ!!!
Потому как запрос должен соответствовать стандартам, синтаксису и правилам построения запросов для конкретной платформы, а не идеям об "обязательности" от отдельно взятых программистов.

угу, стандарт позволяет называть таблички: "t1", "t2", "t3", ..., а поля: "f1", "f2", "f3"...

но программисту который так делает - руки нужно отрывать.
Ничем не обоснованные субъективные крайности.

Может, и запросы вида SELECT * FROM "трам-пам-пам" делать "низзя" ни в коем разе? (задачи/цели разные бывают)
Самое прикольное, что такой запрос сработает даже в случае, когда в связанных таблицах абсолютно идентичный набор полей (ну, например, таблицу саму с собой соединили). И даже сортировку в этом запросе можно по конкретному столбцу выполнить без указания не то что алиаса таблицы, его содержащей, но и имени самого столбца...

Удобство от применения или не применения определенных техник зависит непосредственно от конкретных ситуаций и решаемых задач.
Обращаю внимание: "уровень удобства" - крайне субъективное понятие...
ZyK_BotaNодин умный человек, и мита, однажды сказал: "код пишется в первую очередь для человека, а не для машины."Либо он ошибся, либо кто-то что-то не правильно понял...
Код в первую очередь пишется, чтобы правильно выполнять поставленную при его написании задачу. Соответственно, кто/что этот его будет выполнять - для того он и пишется "в первую очередь". "Красиво написаный" и легко читаемый человеком код, который "не работает" - бесполезен. Соответственно, такой код - фтопку!

ZyK_BotaNsphinx_mvкоторый "не работает" - бесполезенвот что за бред?
от того что ты добавишь альясы, код перестанет работать? оОПораньше спать ложиться не пробовали?
Ибо все с точностью до наоборот: если запрос давал правильные результаты без алиасов, от добавления алиасов результаты правильнее не станут.

Akinasphinx_mvМожет, и запросы вида SELECT * FROM "трам-пам-пам" делать "низзя" ни в коем разе? (задачи/цели разные бывают)Именно! Нельзя!
Ну-ну...
Я посмотрю, как Вы будете писать запрос из десятка таблиц, когда по условиям задачи ВСЕ поля должны быть выведены в результате... И про алиасы не забудьте... Ага...
AkinaОдин болван написал такой запрос и вывалил его результаты в грид. Работает же! Другой болван изменил структуру (изменил количество полей или поменял их порядок). Приложение обалдело и ушло в дальний полёт .
Если у Вас каждый болван без анализа требований и зависимостей, без согласования ни с кем, без тестовых прогонов может изменить структуры данных - это просто невменяемая крутизна!
AkinaБыли бы перечислены конкретные поля конкретных таблиц - всё бы продолжало работать.Во-первых, сослагательное наклонение в программировании не применимо: программа работает или не работает - других вариантов нет!
Во-вторых, практически любая СУБД при разных объемах обрабатываемых данных и разных уровнях конкуренции может требовать принципиально разных подходов к написанию эффективных запросов, которые могут перестать "хорошо" работать в других условиях.
И Вам еще не приходилось сталкиваться с ситуацией, когда изменившиеся требования к системе приводят к необходимости существенной ее ревизии? Если нет - у Вас все еще впереди... Это, вообще-то, в-третьих..
Резюме: правильный ответ на вопрос о "продолжала бы работать, если бы не..." угадать невозможно. Ну, и соответственно...
Akinasphinx_mvКод в первую очередь пишется, чтобы правильно выполнять поставленную при его написании задачу.
Нет. Код должен выполнять поставленную задачу в течение всего срока жизни приложения. В том числе и при изменениях, не влияющих на этот код. Даже изменения, непосредственно не влияющие на конкретный кусок кода могут влиять на него косвенно. В случае с запросами - через обрабатываемые запросом данные. А в случае вашего "болвана", который добавил поля в таблицы - все связанные с этими таблицами запросы были непосредственно затронуты. Так что Вам в первую очередь следует открыть для себя регрессионное тестирование.
AkinaКогда изменение в одном месте рушит исполнение в другом потому, что какое-то прямоходящее сэкономило байты, не указав алиасы или влепив звёздочку вместо полного списка полей, это можно назвать только одним словом - быдлокодерство. Точно так же следует называть и случаи, когда какой-нибудь гений подобными оптимизациями создаёт себе сложности в одном месте, чтобы потом мужественно преодолеть их в другом.Во-первых, "быдлокодерство" - не "звездочка вместо полного списка полей", а отсутствие понимания, что любое , даже самое незначительное изменение в любом , даже самом, на первый взгляд, малозначащем месте программы способно кардинальным образом изменить поведение всей программы "в-целом", независимо от уровня "прямоходячести" конкретных разработчиков, внесших это изменение. Специально для "разруливания" таких ситуаций умные люди используют это .
Во-вторых, наслаждайтесь результатами отвратительной общей организации процесса разработки, в котором категорически отсутсвует одна из базовых частей.

eNosesphinx_mvВо-первых, сослагательное наклонение в программировании не применимо: программа работает или не работает - других вариантов нет! конечно конечно.Более вменяемые контраргументы будут?