Руслан Хакимянов

Тут все ответы одновременно верные, не верные и противоречащие самой задаче.

1. "Ничего не изменилось" противоречит концепции самой задачи: по условиям задачи уже что-то изменилось. Ничего не изменилось в дизайне странице. Изменился объём страницы и увеличилось потребление трафика, а так же объём вычислительных ресурсов необходимых для обработки данной страницы.
   
2. Расходы снизились, т.к. после пересборки и деплоя проекта запустился механизм очистки кэша предыдущей версии проекта и которая занимала больший объём, чем текущая. Расходы увеличились, потому что объём проекта увеличился.
   
3. Скорость - аналогично: проект пересобрался чуток по-другому из-за других хэшей в названиях файлов, которые архиватор пережал чуть более эффективно. Или сжатие страниц не использовалась и скорость отображения страниц замедлилась.
   
4. Износ НЖМД относится к пункту 2, т.к. это часть расходов на обслуживание сервера.
   
5. Электропитание - то же самое: больше байт для обработки - больше затраты на электричество, архиватор сжал эффективнее - меньше байт, меньше затраты.
   
6. Так же и с уязвимостью: дополнительные 43 байта привели к возможности использовать атаку при переполнении буфера в такой странице памяти (ну, условно, конечно). Или наоборот избавили.
   
7. По любому пункту выше (и даже ниже) можно получить как взыскание, так и премию.
   
8. То же самое с выбросами: пользователи получили замедление страницы и со злости очень активно и экспрессивно высказались в адрес владельцев и разработчиков сайта, что привело к более активному дыханию и дополнительным выбросам. Ну или наоборот - пользователи уснули в ожидании загрузки страницы и меньше надышали.
   

Даже формулировка вопроса включает в себя вообще все ответы: к чему могло привести? Это событие могло привести вообще абсолютно к чему угодно - хоть к коллапсу и взрыву сверхновой звезды на другом конце вселенной через миллиард или триллион лет. Так что если отвечать именно на этот вопрос, то да, все ответы верные.

dadata.ru

Переменные окружения всегда хранятся в переменных окружения.

.env-файл - это не переменные окружения, а конфиг, который потом должна подхватить программа и добавить данные из него в свои переменные окружения.
В .NET есть пакет, который делает ровно это: https://www.nuget.org/packages/dotenv.net

В .net для конфигов принято использовать классы и интерфейсы из Microsoft.Extensions.Configuration.
Самый распространённый вариант конфига - файл appsettings.json.

Если мне память не изменяет, то m.e.c по-умолчанию в asp net core настроен так, чтобы тащить конфиги из appsettings, переменных окружения, и аргументов командной строки.

Отдельно можно ещё сделать интеграцию и с другими вариантами конфигурации при помощи "Configuration providers".

Подробнее можно почитать в документации: https://learn.microsoft.com/en-us/aspnet/core/fund...

Запомните одну вещь. Многие её забывают или не знают, и из этого проистекают все их проблемы.

Внешний ключ (FOREIGN KEY) - это ПРАВИЛО. Всё остальное - либо дополнения, либо следствия. Народ начинает рассказывать про индексы и прочее - НЕТ! Не включайте всё это в определение собственно внешнего ключа.

Хотя оно хранится в структуре таблицы, оно является не частью структуры таблицы, а инструкцией, которая будет обрабатываться подсистемой контроля целостности и непротиворечивости данных - есть такая в составе SQL-сервера.

Это правило устанавливает, что при добавлении/изменении значения следует проверить существование нового значения в ссылочной таблице. И наоборот - при удалении следует проверить отсутствие удаляемого значения в ссылающейся таблице. То есть правило работает в обе стороны - влияет не только на таблицу, в которой оно определено, но и на упомянутую в правиле таблицу, при этом в структуре ссылочной таблицы никакого упоминания о существовании этого правила нет. Но, поскольку подсистема контроля - это подсистема уровня сервера, то ей плевать, где прописано.

Это правило может быть дополнено опциями каскадной операции ON DELETE/UPDATE - в этом случае после контроля нового значения подсистема даёт дополнительную команду на выполнение указанных в опции изменений зависящих данных.

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

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

Если хочется так, то нужно идти от количества строк, а не колонок:

display: grid;
  grid-auto-flow: column;
  grid-template-rows: repeat(3, minmax(0, 1fr));