zhenia3003,
1) Что мешает использовать подсветку синтаксиса, размещая сообщение?
2) Что мешает не использовать служебные слова и называть поля БД разумно достаточно, например:


И т.д.

Во-первых, алиасы для сервера. На клиенте они бесполезны. Во-вторых, писать в выходном SELECT'е
занятие а-ля "дурная голова ногам покоя не даёт". В-третьих, читабельность кода повышается, если по имени поля сразу видно его принадлежность. И повторение имени таблицы в начале - это частный случай. Это необязательно так. В-четвертых, отладка больших запросов упрощается, потому что когда у вас 10 таблиц, и в каждой присутствует поле 'Name' и поле 'Date', риск получить неуловимую ошибку увеличивается.

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

Must read: Стив Макконнелл - "Совершенный код".

Я нигде не утверждал, что не надо использовать алиасы. Использовать алиасы для таблиц надо практически всегда. Для полей - по мере необходимости, в основном для вычисляемых и вытащенных из JOIN'ов.
Алиасы для таблиц обычно имеют короткие названия, одно-двух-трех буквенные сокращения от полного имени таблицы. Когда у вас в запросе собирается много данных, например, сложный составной справочник из 20-ти таблиц, у вас алиасы могут иметь вид:

На следующий день вы уже забудете что какой алиас значит и будете бегать по коду глазами, чтобы понять, какое поле к какой таблице относится.
Можно, конечно, алиасы сделать более читабельными, но тогда они будут длинными, и всё преимущество алиасов будет сведено на нет. Это первое.
И второе. В конечном итоге все эти Name'ы надо будет 20 раз прописывать через Name AS MyNewName, т.к. независимо от того, используете вы алиасы для таблиц или нет, в результирующем наборе все одинаково названные поля будут синонимами, и вы либо получите ошибку, либо набор полей с говорящими именами Name1, Name2, Name3 и т.д. Зачем так делать, если можно указать уникальное имя поля сразу в CREATE и забыть об алиасах для полей, оставив их для вычисляемых выражений и ID?
Поэтому корректно моё утверждение звучит так: использование алиасов и правильный нейминг лучше, чем использование алиасов и непродуманный нейминг.
авторP.S. Поля для soft delete тоже предлагаете назвать с именем таблицы ?
is_deleted vs is_news_deleted ?
is_deleted vs is_category_news_deletedПожалуй, тут вы правы, вспомогательные булевы поля являются исключением, я их, в основном, оставляю как есть: Deleted, IsInSomething, etc. Но такие поля обычно не участвуют в больших выборках, где надо в результирующем SELECT собирать 10 полей Deleted (это какая-то специфическая задача). Они обычно сидят в WHERE или JOIN ON.
Но если булево поле не вспомогательное и пересекается с другими подобными полями, его имеет смысл именовать расширенным образом.