Выходят непонятные каракули в удаленной базе данных. В то время как в локальном все работает хорошо, что делать?

SagePtr,

логичнее указывать в клиенте.

Это логично.

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

Особенно если учесть такую мелочь, что результат выполнения команды SET NAMES локален для соединения. Так что если используется пул соединений, или если посередь процесса соединение порвётся и будет автоматически восстановлено, то результат выполнения команды останется "где-то там"...

Выходят непонятные каракули в удаленной базе данных. В то время как в локальном все работает хорошо, что делать?

Дык коли по дефолту, то не настроено, и надо настроить...

Выходят непонятные каракули в удаленной базе данных. В то время как в локальном все работает хорошо, что делать?

SagePtr,

При подключении к базе данных нужно тоже кодировку указывать

Ну скорее можно, чем нужно. А вот что действительно нужно - так это правильно настроить. Как клиентскую секцию INI-файла сервера, так так и параметры соединения в приложении. И тогда дополнительно указывать ничего не нужно.

Конечно, всё это при условии, что есть административный доступ к управлению сервером. Ну а если нет - тогда да, костыли, куда деваться.

Выходят непонятные каракули в удаленной базе данных. В то время как в локальном все работает хорошо, что делать?

Только если криво установлены параметры соединения. И лучше не пользоваться костылями, а указать правильные настройки в my.ini#[client].

Как найти в mysql ряд где значение json массива равно значению?

На показанных данных - только через задницу. Если в поле перемешаны объекты и массивы (да ещё поди и структура не фиксирована), то неизвестно, как именно работать со значением каждой отдельной записи.

Список ORDER BY оконной рамки RANGE имеет общий размер 1020 байт. Максимально поддерживаемый размер равен 900 байт. Как исполнить запрос?

убрал order by и запрос исполнился

А вот это зря... ORDER BY death.Date надо было оставить. А то он же ж тебе может посчитать накопление с отфонарным порядком дат.

Список ORDER BY оконной рамки RANGE имеет общий размер 1020 байт. Максимально поддерживаемый размер равен 900 байт. Как исполнить запрос?

А за каким хреном сортировка по death.location в группе по death.location? поверь на слово, во всей группе в этом поле одно и то же значение...

Выходят непонятные каракули в удаленной базе данных. В то время как в локальном все работает хорошо, что делать?

Для начала

SHOW VARIABLES LIKE 'char%';
SHOW VARIABLES LIKE 'coll%';

и сравнить. Несинхронно? перенастроить.

Далее - проверить, нормализовалось ли, но не из PHP, а строго из CLI, причём при одинаковом CHCP. Неровно? Скорее всего криво залил, при неровных настройках, перезалей.

Ну а дальше уже настройки PHP и браузера - тут я пас.

Как удалить лишнее в ячейке?

Формула не может изменить значение ячейки-источника. Она может только посчитать значение на основании значений других ячеек и отобразить его.

Как удалить данные в базе данных при импорте из CSV?

ссылку на какой нибудь пример

INSERT ... ON DUPLICATE KEY UPDATE Statement

Как удалить данные в базе данных при импорте из CSV?

Может быть есть более правильный вариант...

Правильный вариант - это импортировать средствами MySQL (LOAD DATA LOCAL INFILE .. REPLACE). А читать файл на PHP и потом пихать по одной записи в таблицу - это дурь.

Как получить позицию записи в таблице относительно сортировки MySQL?

А точная версия MySQL какая?

И если есть несколько записей с таким RATING - то что должно выводиться?

Как SQL запрос получить в JSON?

1. Уточните - JSON нужно сформировать на стороне SQL-сервера или на стороне PHP?
2. Укажите точно используемую СУБД. Включая точную версию.
3. Покажите пример вывода показанного запроса (2-3 записи) и желаемый для именно этих данных выходной JSON.

Как вывести запросом менеджеров, у которых з/п не менялась за последние 2 года?

Kathoreary, это будет "у кого з/п не менялась в течение первых 2 лет момента приёма на работу". А в задании - в течение последних 2 лет.

Как вывести запросом менеджеров, у которых з/п не менялась за последние 2 года?

Вот те же данные в виде fiddle.

Теперь по делу.

Во-первых, что имелось в виду под словами "за последние 2 года"? Обычно такое говорят, когда надо считать "от сегодня" - но у Вас там даты гораздо раньше, т.е. ни у кого за именно последние 2 года никаких изменений нет.

Во-вторых, я вроде вменяемо просил 4 записи, и для каждой разная комбинация фактов. А у Вас две пары близнецов-братьев. Так не пойдёт.

В общем, поправьте fiddle и вставьте туда нормальные данные. Добавьте ссылку плюс эталонный ответ для этих данных в текст вопроса

Как вывести запросом менеджеров, у которых з/п не менялась за последние 2 года?

Приведите пример исходных данных (CREATE TABLE + INSERT INTO для 4 сотрудников - принят ранее 2 лет / в последние 2 года, зарплата менялась / не менялась) и требуемый результат запроса.

Как лучше организовать сводную таблицу?

у меня идет десятки тысяч вставок в час.

Не смешно. 100 тыс. вставок в час - это 30 запросов в секунду, для более-менее сервера вообще ниачём.

Если делать доп-проверки есть ли нужная запись в справочнике это сильно снизит производительность.

Это Вы на потолке подсмотрели? я про "сильно"... При правильно построенном запросе и правильном индексировании разница будет максимум в несколько процентов. А может и вообще не определяться.

Как можно в моем случае нормализовать структуру?

Структуру, которую никто, кроме Вас, не видел? Вы серьёзно?

Как лучше организовать сводную таблицу?

как это сделать автоматически?

А это зависит от того, какая сейчас структура, как сейчас выполняется вставка. какая структура будет создана...

Основные варианты
1. Триггер.
2. Вставка в новую структуру запросом, использующим CTE, в котором выполняется попытка вставки новой записи в словарь.

Как лучше организовать сводную таблицу?

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

Вот уж точно не причина. Ничто не мешает по появлении нового значения тут же добавить его в словарь. Причём это можно делать и автоматически.

Однако в меню мне нужно отображать все уникальные значения из него. DISTINCT делать по нему крайне долго. Получается нужна какая-то таблица которая пересчитывается постоянно.

Всё вышеописанное - это не повод делать через задницу. Нормализуйте структуру. Заодно настоятельно рекомендую и всю остальную структуру проанализировать - вряд ли это был единственный косяк.

Как отсортировать результат по количеству "пойманных" id?

а зачем тут вообще тогда left join, вроде и без него все считает как надо xD

Если удалить LEFT JOIN - получится строго то, что написано в ответе.

зачем тут вообще тогда left join

Если recipe_ingredients ( recipe_id , ingredient_id ) и ingredients ( id ) определены как уникальные - нафиг не нужен. Иначе - влияет.