Rsa97

Не нужно, но и ошибкой не будет

UNION по умолчанию выполняется как DISTINCT, то есть в результирующей таблице будут только уникальные строки, вместо трёх двоек будет включена только одна. Замените UNION на UNION ALL.

mysqli_num_rows() expects parameter 1 to be mysqli_result, boolean given

Значит в $result записан не результат запроса, а логическое значение. Читаем описание функции mysqli_query:

Возвращает FALSE в случае неудачи. В случае успешного выполнения запросов SELECT, SHOW, DESCRIBE или EXPLAIN mysqli_query() вернет объект mysqli_result. Для остальных успешных запросов mysqli_query() вернет TRUE.

Запрос SELECT, значит из логических значений могло вернуться только FALSE, следовательно в запросе ошибка.
Внимательно читаем запрос - вот она, лишняя запятая.

И, до кучи, ваш код не защищён от SQL-инъекций. Вместо прямой подстановки переменных в запрос используйте плейсхолдеры.

CONCAT()

find /srv/sh/folder/* -maxdepth 0 -type d -exec bash -c 'cd {} && tar --remove-files -czf archive.tgz *' \;

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

P.S.
Ок, пусть будет блог. Комментировать посты в нём можно будет? Тогда надо как-то эти комментарии записывать. Лайки ставить или карму править - это тоже запись данных. Даже простейший счётчик просмотров это уже изменение данных. Вот на примере такого счётчика обычно и поясняют необходимость атомарности и блокировок. Представьте, что два человека одновременно открыли пост блога и скрипты увеличивают счётчики прочтения, старое значение 99.

Скрипт 1: прочитать файл "счётчики"
Скрипт 2: прочитать файл "счётчики"
Скрипт 1: найти в файле счётчик поста, получили 99
Скрипт 2: найти в файле счётчик поста, получили 99
Скрипт 1: увеличить счётчик поста, получили 100
Скрипт 2: увеличить счётчик поста, получили 100
Скрипт 1: записать файл "счётчики"
Скрипт 2: записать файл "счётчики"

То есть вместо ожидаемых 101 в счётчике всего 100. Значит перед изменением любых данных необходимо заблокировать файл на запись, считать из него актуальные данные, внести изменения, записать файл, разблокировать его. Ну а поскольку это json, то считывать и записывать файл каждый раз придётся целиком. Если при изменении данных меняется связь с данными в других файлах, то во избежание нарушения целостности блокировать придётся все связанные файлы.

Ну и поиск по данным, скажем десять самых читаемых постов. В файловом варианте вам придётся считать весь json, и отсортировать его, тогда как в БД при правильной расстановке индексов это действие выполняется в один запрос с линейным получением первых десяти записей по индексу.

По стандарту приоритет MX-записи - беззнаковое 16-битное число от 0 до 65535, больше никаких ограничений нет.
При отправке почты выбирается MX-запись с наименьшим приоритетом. Если таких записей несколько, то из них выбирается случайная. Если сервер недоступен, выбирается запись со следующим приоритетом и т.д.

var re = /(?:^|\s)(?:xs|sm|md|lg|xlg)-(bottom|top|left|right)(?:$|\s)/;
$('[data-toggle="popover"]').each(function() {
  var classList = $(this).attr('class');
  var ok = re.exec(classList);
  if (ok !== null) {
    $(this).popover({
      trigger: "hover",
      container: "body",
      placement: ok[1],
      html: !0,
      viewport: {
        selector: "body",
        padding: 2
      },
      template: '<div class="popover"><div class="arrow"></div><h3 class="popover-title"></h3><div class="popover-content"></div></div>'
    });
  }
});