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Во-первых, сослагательное наклонение в программировании не применимо: программа работает или не работает - других вариантов нет! конечно конечно.Более вменяемые контраргументы будут?

Akinasphinx_mvЯ посмотрю, как Вы будете писать запрос из десятка таблиц, когда по условиям задачи ВСЕ поля должны быть выведены в результате... И про алиасы не забудьте... Ага...
Прекрасно пишутся. И прекрасно документируются. Никаких проблем при этом не возникает.Пишите! Я Вам тратить Ваше время на совершенно непродуктивное исполнение Ваших персональных "пунктиков" не запрещаю.
Akinasphinx_mvЕсли у Вас каждый болван без анализа требований и зависимостей, без согласования ни с кем, без тестовых прогонов может изменить структуры данных - это просто невменяемая крутизна!
Необходимость анализа зависимостей, согласований с кем-либо и тестовых прогонов при добавлении полей или изменении их порядка возникает не у меня. У меня как раз этой проблемы нет и быть не может. Потому что я не раскладываю себе "грабли для наступания". То, что есть у меня, изначально предусматривает возможность такого рода изменений. А кто не хочет быть предусмотрительным заранее - пусть впоследствии трахается с регрессионным анализом. Мне не жалко.Смеялся... Долго...
В очередной раз порадовало, что внесение любых произвольных изменений любым "прямоходящим болваном" и только по желанию его левой пятки - это все еще "best practice", в которой "все учтено"... Ага, ровно "стопицот мульенов раз"...
Akinasphinx_mvпропущено...
Во-первых, сослагательное наклонение в программировании не применимо: программа работает или не работает - других вариантов нет!
Когда перечислены конкретные поля конкретных таблиц - продолжит работать. Так лучше?Не лучше.
Полезность от полного перечисления ВСЕХ полей из всех таблиц в запросе вместо "звездочки" - нулевая. Если не вообще отрицательная. Хотя бы из соображений, что простоты понимания результата запроса оно не добавляет.
Зато "галочку" в процессе соблюдения формальных правил, естественно, поставить можно.
Akinasphinx_mvВо-первых ...
Во-вторых ...
в-третьих ...

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

eNosesphinx_mvпропущено...
Более вменяемые контраргументы будут? зачем? ведь все прекрасно знают, что патчей в природе не существует :)
А у Вас считается, чтот после наката патчей (на любую из частей) "программы" она не меняется и остается все той же самой?
Забавный подход... Можно посмеяться...