ThunderCat

Для такого маленького изображения я бы передавал только самый большой вариант.

Экономия с точки зрения пользователя тут будет лишь в том случае, если везде используется 40*40, и, например, только в редакторе профиля показывается 100*100. Тогда люди в 99% случаев не будут качать лишние пиксели. Но их объём настолько мал, что заморачиваться нет смысла.
Если же разные размеры используются повсеместно, то, делая три отдельных изображения, вы увеличите объём трафика на 21%, т.е. сделаете хуже и себе, и пользователю.

Если массив не очень большой - сделайте всё одним запросом:

<?php
$data = [
    ['a' => 1, 'b' => 2, 'c' => 3],
    ['a' => 1, 'b' => 2, 'c' => 3],
    ['a' => 1, 'b' => 2, 'c' => 3],
    ['a' => 1, 'b' => 2, 'c' => 3],
    ['a' => 1, 'b' => 2, 'c' => 3]
];

$query="INSERT INTO t (a, b, c) VALUES " . implode(
    ', ', 
    array_fill(
        0,
        count($data), 
        '(' . implode (', ', array_fill(0, count($data[0]), '?')) . ')'
    )
);

echo $query;

$values = array_reduce(
    $data,
    function($ac, $el) {
        return array_merge($ac, array_values($el));
    },
    []
);

var_export($values);

$q=$pdo->prepare($query);
$q->execute($values);

Здесь вы можете протестировать код

почему этот запрос просматривает так много записей?

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

Подобный подход, кстати, ответственен за то, что при одинаковом количестве отбираемых записей чем больше начальное смещение, тем больше фактическое время выполнения запроса, и на объёмных выборках даже используются специальные методы ускорения работы.

Мне возвращается первые 3 строки.

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

Вот, полюбопытствуйте: FIDDLE. Кстати, забавно, что без хинта оптимизатор выбирает вовсе даже не первичный индекс... Более того, в данном конкретном случае этому есть совершенно точное и строгое объяснение - попробуйте его найти.

Это не задача Апач, любую задачу надо решать тем инструментом, который для этого предназначен. Для блокировки используется iptables, и надстройка ним fail2ban. Они эту работу сделают намного эффективнее.

Во-первых, нет такого запрета.
Во-вторых, в приведённом примере это действительно имеет смысл, поскольку у каждого поставщика цены могут меняться независимо от цен других поставщиков.
Если не делать связь таблицы "Товар-Поставщик" с таблицей "Динамика цен", то это только усложнит структуру, а пользы не добавит. Поэтому да, есть смысл делать такую связь.

Альтернативный вариант - это сразу сделать большую таблицу "Товар-Поставщик-Дата-Цена" и использовать её двояко: (1) для связи "Товар-Поставщик" используется ключ "Товар-Поставщик", (2) для динамики цен используется ключ "Товар-Поставщик-Дата". Ну, это, видимо, не соответствует нормальной форме, так что спорный вариант. Но считаю, что он имеет право на жизнь, в зависимости от количества данных, в зависимости от популярных запросов и т.д. Иногда полезно, а иногда не полезно.

Смотрим здесь. Получаем для обычного INT 4 байта на одно число, для BIGINT 8 байт.
200 * 4 * 10'000'000 = 8'000'000'000 или 8Gb.
200 * 8 * 10'000'000 = 16'000'000'000 или 16Gb.
По нынешним меркам сущие пустяки.
Хранить, конечно же, нужно в нормальной форме, иначе суммирование придётся делать в приложении.

в БД обычно хранится "ссылка" \ хеш на файл, а сам файл может хранится либо просто на диске в системе, либо на подключенном S3 к примеру, это уже как по деньгам \ удобству итд...

Отследить трекерами реестра и файловой системы - что создается, обычно это папка в program files, ключи реестра в HKEY_LOCAL_MACHINE и ярлыки - и удалить это все скриптом, не забыв перед этим прибить возможно запущенный процесс этой программы.

На будущее - в msi надо не инсталлятор оригинальный запихивать, а последовательность действий из этого инсталлятора. Отловить можно все - как написал выше.

1. Адреса должны быть относительными всегда
2. Место хранения следует задавать переменной

1. В реляционных базах - обычно это признак чего-то нехорошего, хотя сейчас во многих есть нативная поддержка JSON (в постгресе так она вообще очень хорошая)

Это строки в JSON формате или отдельные таблицы?

Можно и так и так, но
2. Если бы я хотел такую структуру получить в ответе, то geo я бы хранил просто в отдельных двух колонках в адресе. Сам адрес - в отдельной таблице. Компанию - тоже в отдельной таблице.
А для выдачи результата - джоинил.
А если это всё относится только к сущности пользователя (тоесть нету такого, что несколько пользователей относятся к одной организации, которую нужно дедуплицировать) - можно всё в одной таблице и хранить, но в разных колонках (и просто при выдаче результата приводить это к объектной модели)
Либо же иметь одну json-колонку, в которой иметь произвольное количество дополнительных/опциональных полей.

На сколько популярно и корректно хранить данные в столбце в виде JSON строки?

А это зависит от того, что с этими данными делать.

Если сохранить/вернуть - да, вполне.
Если найти по фрагменту - 50/50, и зависит в основном инструментов, имеющихся в конкретной СУБД.
Если выполнить более сложную обработку (сумма, в т.ч. с накоплением, среднее, медиана и пр.) - скорее нет.
Если использовать для связывания по фрагменту - почти наверняка нет.

самый простой вариант это прописать классы от родителя
.main-pagination .swiper-pagination-bullet {}