Freeman

Наркомания, но должно работать

SELECT
    CASE 
        WHEN FirstField LIKE '*о*' THEN FirstField
        WHEN SecondField LIKE '*о*' THEN SecondField
    END AS Field
FROM Table
WHERE FirstField LIKE '*о*'
OR SecondField LIKE '*о*';

UPD
Хорошо, продолжаем наркоманить :D

С учетом комментария Vitsliputsli

SELECT DISTINCT
    CASE 
        WHEN t1.FirstField  LIKE '*о*' THEN t1.FirstField
        WHEN t2.SecondField  LIKE '*о*' THEN t2.SecondField
    END AS Field

FROM Table t1

LEFT JOIN Table t2 ON 1=1

WHERE t1.FirstField LIKE '*о*'
   OR t2.SecondField LIKE '*о*';

Добавили distinct чтобы не было повторений, добавили join той же таблицы, по t1 проверяем подходит ли FirstField по t2 - SecondField. Единственный вопрос, а допустимо ли в этой задаче использовать join)

PS разумеется запрос говна, про оптимизацию речи не идет

Этот мануал в вашем случае не подходит. Там синхронизация односторонняя. Вы отправляете не на сайт, а в репозиторий на сервере. Затем хук извлекает содержимое ветки master в каталог с файлами сайта, затирая всё что там ранее мог изменить пользователь через админку.

И репозиторий на сервере никак не меняется, при изменении файлов сайта. Поэтому аналогия с гитхабом не работает. Гитхаб вам сразу показывает содержимое репозитория, сами файлы там не лежат в какой-то отдельной папке.

если нажать pull или fetch all, то локальная версия изменений на сервере не видит.

А разве должен видеть? Fetch/Pull скачивает не файлы из рабочего каталога, а коммиты из репозитория. Это вообще разные сущности. Чтобы в репо попали изменения, их нужно коммитить, только так и не иначе.

Предлагаю не создавать bare-репозиторий без рабочего каталога, а инициализировать обычный репо прямо в каталоге сайта. Обновления не проталкивать через push, а забирать через pull, потому что гит не сможет отправить push в текущую ветку. Чтобы забрать изменения файлов с сервера, их нужно предварительно коммитить разумеется, так как pull скачивает не файлы, а коммиты. Pull лучше делать на чистом от изменений рабочем каталоге, поэтому можно запускать простой скрипт

git fetch # скачать обновления заранее, чтобы не ждать во время обновления файлов
git stash # временно спрятать локальные правки
git pull # применить обновления к сайту
git stash pop # вернуть локальные правки обратно

Это немного помогает избежать конфликтов между вашими локальными изменениями и изменениями из внешнего репозитория. Но лучше предварительно закоммитить изменения на сервере и перенести их на рабочий компьютер.

Я таким способом в своё время успешно синхронизировал правки между компьютером разработки и основным сервером, где работал продукт. Там тоже часть файлов изменялось сервером во время работы. Скрипт отрабатывает достаточно быстро, чтобы сервер не успел заметить откат файлов при stash.

Единственное достоинство для резервного копирования у ssd - это высокая скорость (если выбирать nvme) доходящяя до 5 гигабайт в секунду чтения и примерно в 8 раз медленнее запись (зависит от технологии, но те что быстрее - на порядок дороже).
Чтобы получить такую же скорость на основе hdd, нужно городить raid0 (без резервирования) минимум из 10 дисков (скорость одного современного диска 150-300мбайт/сек, осторожно с дисками с черепичной записью, у них скорость записи падает в 10 раз по сравнению с чтением).

Они дороже за гигабайт (особенно если выбирать серверные, надежные, с умным контроллером и какими то гарантиями), причем на порядок.

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

Поэтому, единственное, зачем имеет смысл использовать ssd для резервного копирования - это вынужденная оперативность, когда нужно максимально быстро сделать резервную копию и продолжить работу. И в этом случае ssd можно использовать как временный буфер. И да, почти тот же функционал (возможность получить замороженное состояние данных чтобы была возможность копировать их на медленный носитель) можно получить программным способом, например с помощью снапшотов файловой системы или master-slave репликацией базы данных на слабую машину, с которой уже и снимаешь копию (это нужно если сам процесс резервной копии замедляет работу на столько, что это не приемлемо).

Поэтому не советую покупать для задач резервного копирования ssd только потому что это 'модно молодежно'

Использовать что-то типа Ventoy.

ховер и подобное – состояние html/документа.
a скролл страницы – состояние окна браузера, не документа.

css этим не управляет.

Сообщество считает, что всё это бессмысленные ужимки, которые в 99% случаев используются только для того, чтобы прикрыть крайнее убожество кода. Серьёзные продукты никто не шифрует. Чем, в частности, объясняется заброшенность всех этих, на первый взгляд многочисленных, проектов, которые не выходят из стадии "мы тут с одноклассниками придумали крутую штуку". потом одноклассники либо умнеют и перестают теребить ерунду, либо находят занятие более интересное, чем пхпе.

Сам по себе код мёртв. Он устарел ещё до релиза. В работе софта важна не дискетка с исходниками, а поддержка. Вот поддержку и надо продавать. И не дрожать над каждым вором. Потому что защита от одного вора отпугивает 10 честных покупателей.

Плюс всегда есть SAAS.

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

Уже по наличию нумерованных столбцов сразу видно, что структура БД кривая. А текущая проблема делает это еще более наглядным: собственно, сама постановка вопроса, "как задать имя столбца через переменную", говорит о том, что имя колонки используется в условии. То есть оно должно быть значением в строке.

Здесь нужна связанная таблица, один ко многим, и она сразу снимет все проблемы, а запросы станут мягкими и шелковистыми:

UPDATE link_count SET count=count+? WHERE link_id=? and number=?

Автономные приложения под линуксом надо запускать как сервисы через systemd.
Как это сделать можно почитать тут - https://habr.com/ru/companies/timeweb/articles/759966/

С помощью этого, можно будет выставить политику повторного запуска при остановке, логи можно в syslog сохранять и подобное.
Так как ты запускал это все в фоновом режиме и вышел, то родительским процессом стал init, все логи потерялись. Максимум можно дамп ядра получить, но это еще при выставленных настройках.

Также я не услышал про логи (в каком они виде) - если есть лог файл, то смотри там, иначе ничего сказать не могу.

Могу также порекомандовать запускать это все в докере. Немного замороченно, но та же самая функциональность (логи и рестарт), что и в systemd сервисе.

Имена полей подставлять нельзя.

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

Статические - обычно идут вместе с твоим софтом, интегрируются в исполняемый файл.
Плюс - можно юзать любую версию.
Минус - каждая программа будет грузить в память свой экземпляр всей библиотеки, и если библиотека большая (а зачастую код print(stdout,"hello world) гораздо меньше, чем библиотека которая собственно выводит строку), то расходуется лишняя память и лишнее место на диске.

Отношения к блокировкам процессов ни те ни другие не имеют