mletov

У каждого формата есть спецификация - вот ее и читайте

С практической точки зрения - надо смотреть план исполнения запроса. Там будет указан тип сканирования и предикат как БД фильтрует строки. Если план для
SELECT (1)
не отличается от
SELECT (*)
то тогда можно считать что это - одно и тоже.

Почему обсуждение теоретического SQL я считаю здесь вредным и бесполезным? Потому что ни я ни
кто либо из присуствтующих стандарт SQL не читал. Это - закрытый и платный документ. И
обычно нам достается не текст стандарта а текст самой реализации на Oracle/PG/MySQL.
Вот и говорим о реализации а не о стандарте. А реализации бывают разные. В оракле например
требуется фейковая табличка dual для пустых безтабличных запросов. В других dbms
- фейковая табличка не нужна. Синтаксис другой.

Если кто-либо из присуствующих читал стандарт SQL и знает как объявлено поведение count() - то прошу
привести хотя-бы цитату.

Бизнес должен понимать что вы ему предлагаете. По сути эту идею можно продвинуть только под соусом разработки новой фичи. В противном случае у вас будет сильное непонимание. Все что вы предлагаете - это NFR. Не-функциональные требования. Шестая версия дотнет. Асинки. Обжекты. Бизнес не понимает как ему это дальше продавать.

Я-бы сказал что просто так взять всё и переписать - это гиблое дело. Пойдут баги и бизнес попросит либо срочно исправлять либо откатить это назад до старой версии. Это - фиаско. Очень часто бывает так что старый и плохой код завязывается на какое-то странное поведение API которое плохо документировано и чёрт-пойми-как-работает. Но работает. Я много таких аномалий видел. И ты его исправляешь по фень-шую как должно быть и становится ... (!) еще хуже. Особенно большая беда с мультипоточкой и интеграцией например с операционкой или сторонними нативными либами.

Если вы имеете силы и смелость - то пишите план (желательно на пол-года) на рефакторинг. Шаг-за шагом. Сначала - покрытие всего тестами. Потом миграция версий тоже мелкими шажками. И все это (!) параллельно с разработкой новой фичи которую бизнес одобрит. Только так.

Что может быть и что можно сделать. Я бы начал с бэкапов данных. А если есть возможность переустановить или откатить на момент когда все работало то я бы так и сделал т.к. нет гарантий, что вручную все до конца удалится и не останется уязвимостей. А дальше нужно мониторить, вовремя ставить обновления, проверять на вирус и т.д. У битрикса же вроде были свои антивирусы и файрвол.

Нужно добавить заголовок Host, для браузера придется ставить расширение.
Обычно на одном айпи адресе могут хостится несколько сайтов (от пары до десятка или сотни)
Так называемые виртуальные хосты получают заголовок Host откуда извлекают информацию, к какому сайту пользователь хотел обратиться. Если веб сервер настроен именно так, то по айпи зайти не выйдет или будет выбрасывать на дефолтный сайт (зависит либо от настройки администратором, либо от вебсервера, часто выдает первый по алфавиту, могут быть любые другие варианты)

яндекс бизнес

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

SMS-рассылки приходится согласовывать с ОПСОСами. Каждый из них высылает чек-лист, с которым надо согласовать формат рассылок, чтобы соответствовать статусу сервисной SMS. Самая жопа, когда рекомендации разных ОПСОСов друг другу противоречат.

Баги бывают разные. Действительно баги, и не совсем баги, и совсем не баги. Без конкретики это как обсуждать сферического коня в вакууме. По каждому отдельному случаю надо смотреть и разбираться, и по ситуации принимать решение. Т.е. работать надо.

Это типичная задача CMS. Только в них редко страница на чистом HTML добавляется. Обычно новая страница создаётся на основе предустановленных шаблонов и плагинов. Как всё это реализуется можно посмотреть на гитхабе в исходниках опенсорсных CMS.

А грузинские можно? Подозреваю, что нет. Ограничьте латинским алфавитом, цифрами...

Потому что MSSQL, Oracle , DB2 это энтерпрайз в которые вколочены тысячи человеко-лет.

И опенсорсные записные книжки с sql интерфейсом не дают таких возможностей.

ЗЫ кстати реально российская СУБД https://www.linter.ru/

В каких-то компаниях не находят ресурсов, чтобы слезть с западной проприетарщины, и будут теперь годами сидеть на единожды купленной лицензии, без обновлений и без развития. В каких-то ещё идёт процесс миграции со старых систем на новые, и специалисты по MSSQL/Oracle будут нужны ещё несколько лет. В каких-то остались небольшое количество доживающих проектов, которые мало используются, не развиваются и естественным образом потеряют актуальность с годами, а значит дешевле держать под них пару спецов, чем переписывать и мигрировать.

Первая ссылка в Гугле по запросу php ton sdk
https://github.com/extraton/php-ton-client

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

Если вы под "багом" подразумеваете то, что четко описано в ТЗ и не выполнено, то нет, платить не должны. Но если вы подразумеваете под "багом" что-то вроде "так это же очевидно, что оно должно так работать", но не описали в ТЗ, то да! Это будет не баг со стороны программиста, а баг со стороны вас, как ПМ-а. Ибо, что не сказано, то есть ложь! Если вы не удосужились описать четкий функционал, что должно вводится, что должно получиться на выходе, как это должно работать, то не ждите "очевидных" для вас решений, так как все, что очевидно для вас, не очевидно для других.

В данном случае не нужна таблица. Тут нет табличных данных.
Уместнее использовать flex или grid.

Может. Смотри на пользовательское соглашение конкретного сайта и лицензию, под которой контент распространяется