Как выбрать значения из БД по JSON?

aspirantes, Сравнивать надо не исходное строковое представление, а полученное из JSON.

WHERE json_column = CAST( json_literal AS JSON )

Как выбрать значения из БД по JSON?

aspirantes, если jsons есть переданный в код литерал-значение, то данный ниже ответ некорректен.

https://dbfiddle.uk/1JnYUt7s

Как выбрать значения из БД по JSON?

Не везде сравнивает, как строки.

Вот эта фраза непонятна от слова "совсем".

Во-первых, чётко определите, что Вы желаете сравнивать - JSON или их строковое представление. Это не одно и то же.

Во-вторых, всё же чётко выскажитесь, что именно нужно и над чем. Например, из показанного запроса в принципе не понять, что есть json и jsons.. поля? литералы? что-то ещё? Наилучшим вариантом будет публикация небольшого примера для вариантов "равно" и "не равно".

я JSON записываю, а потом пытаюсь его же сравнить с записанным.

Если тип данных поля именно JSON, то это бессмысленное занятие. Почитайте в документации про то, в каком виде/формате хранятся данные этого типа, что ли..

Как дать доступ к принтеру в другой подсети?

Ню-ню.. во роутер-то обрадуется, узнав, что он - мост.

Как дать доступ к принтеру в другой подсети?

Имеется следующая структура. Комп 1 (192.168.20.200)-коммутатор (192.168.20.2)-роутер кинетик (192.168.20.244 от коммутатора, 192.168.1.1 свой) - принтер по вайфаю (192.168.1.90).

Это не структура, это фигня какая-то.

Рисуйте - девайсы, их интерфейсы и соединения. По каждому узлу и по каждому интерфейсу каждого узла полную раскладку по всем сетевым настройкам (адрес-маска-NAT, имеющиеся маршруты, виланы, маппинг портов и т.п.).

А нафига нужно было указывать адрес свича, я вообще не понял...

Как добиться баланса между скоростью и производительностью при импорте ~200к строк в базу данных?

на данный момент определяются в коде (условно валидность / не валидность строки).

Я верно понимаю, что это определение может выполнить только приложение, его нельзя провести на стороне SQL-сервера?
Если так, то загрузка всего CSV в программу, расчёт дополнительных данных, сброс результата в новый CSV и его загрузка в таблицу через LOAD DATA будет скорее всего наиболее быстрым решением. Тут если что и может затормозить - так это файловые операции.. правда, у LOAD DATA есть один недостаток - если при загрузке произойдёт ошибка, то уже загруженная начальная часть останется в данных (LOAD DATA не транзакционный запрос).

Как добиться баланса между скоростью и производительностью при импорте ~200к строк в базу данных?

через файл вставка проходит быстро - 2,5 секунды в среднем

Вставка 200к записей по 15 байт на рыло из CSV за 2.5 секунды? это ну очень долго..

Как добиться баланса между скоростью и производительностью при импорте ~200к строк в базу данных?

нужно их дополнить данными

Откуда берутся эти дополнительные данные?

Как правильно сделать запись логов?

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

Как правильно сделать запись логов?

У MariaDB это есть искаропки. https://mariadb.com/kb/en/temporal-tables/
Впрочем, если и не почти всё, то многое - вручную, так что несложно перенести это в MySQL.

Как избежать ошибки 2013?

Если после этой ошибки приходится перезапускать MySQL - проблема скорее всего в нём или его базовой ОС, причём проблема системная.
Если достаточно перезапустить приложение - проблема скорее всего в нём, коннекторе или локальной для приложения ОС.
Если достаточно повторно выполнить запрос - проблема скорее всего в конкурентных приложению процессах и/или соединениях.
Если другие запросы выполняются нормально - проблема скорее всего в неоптимальном запросе и/или отсутствии нужных индексов, плюс выросший объём данных.

Как найти к какому коммутатору подключена розетка?

Возможно, автор как раз и начинает работы по документированию...

Почему скрипт не понимает, что данные в MySql изменились?

ilezovofficial, я говорю о кэшировании на стороне клиента.

Почему скрипт не понимает, что данные в MySql изменились?

Отключить кэширование результата запроса. Или, например, параметризовать его.

Как отсортировать записи по условиям?

Ну разве что переместить всё это прямо в выражение сортировки, да избавиться от CASE...

Как открыть портов на DLink-615 кроме 22, 80 и 443?

Похоже, Вы напрочь не понимаете, что такое "открыть порт". В Вашем понимании это, вероятно, "чтобы сканер сказал, что эти порты открыты". Но для этого надо не только обеспечить свободное прохождение трафика на этот порт и обратно, но ещё и наличие сервиса, который будет обрабатывать обращения по этому порту. Имхо для портов 8080 и 25565 второй пункт не выполнен...

Как избежать коллизии по данным?

На уровне интерфейса это нереально. Заблокировать web интерфейс? Пользователь обновит страницу и повторит.

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

Как избежать коллизии по данным?

Pantuchi, не, я не понял...

Во-первых, Вы специально и сознательно делаете всё, чтобы описанные коллизии были не только возможны, но и почти что неизбежны.

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

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

В общем, проблема не в SQL-сервере.

Как избежать коллизии по данным?

Pantuchi, а создание объекта - это за пределами MS SQL, то есть это не его проблема. Решается, впрочем, легко - если транзакция обломилась, объект уничтожается.

Как избежать коллизии по данным?

Пользователь не дожидаясь ответа обновляет страницу и снова создает объект. Получается уже две транзакции в очереди. По итогу когда очередь доходит до выполнения имеем в базе два одинаковых объекта (созданных вплоть до ms) что ломает логику программы.

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