Как верно написать рекурсивный запрос sql?

Указанная попытка - это решение совершенно другой задачи. А здесь нужно просто отсортировать:

SELECT
    employeeid
FROM employees
ORDER BY COALESCE(managerid,employeeid), CASE WHEN managerid IS NULL THEN 0 ELSE employeeid END

при условии, что employeeid всегда больше 0.
Но, вышезаданный вопрос остается, как теперь отличать employee от manager?

Какие БД используют крупнейшие торговые сети для хранения заказов?

Saboteur,

Короче я прикопался к вашему утверждению, что "высоконагруженное это не для sql"

Не-не, не так. Скорее "хорошего решения нет, поэтому используем то, что есть". И часто это будет sql.

Реляционки делают свою задачу, и если нужно ее делать быстро, ищутся решения для адаптации (кластеризация, шардизация)

Кластеризация или репликация помогут с чтением, но с записью никакого выигрыша. А шардирование не всегда применимо. Если к примеру, есть достаточно большая БД, что уже началась сильная деградация, а критерий шардирования не выбрать, то масштабировать не получится. Но это не значит, что можно будет в любой ситуации заменить nosql с бесконечным линейным расширением.

Какие БД используют крупнейшие торговые сети для хранения заказов?

Saboteur,

Отлично реляционные СУБД подходят для нагруженных систем. Просто не нужно путать когда для проекта подходит реляционная база, или другая. Это явно зависит не от "нагруженности", а от типа данных и архитектуры.
Некоторые вот даже TSDB путают с реляционкой.

Ага, отлично подходят, если не хранить много данных, и отказаться от большей части требований реляционнной модели. Речь не о том, что есть другое идеальное решение, речь о том, то что хотя они используются, это не значит, что они "отлично подходят". Будь оно так, то не внедряли бы зоопарк из различных решений, чтобы компенсировать проблемы реляционных СУБД.
И еще как выбор СУБД зависит от нагрузки, потому что вся архитектура зависит от нагрузки. Если это было не так, то мы бы всегда строго соблюдали реляционную модель, выставили бы serializable, писали бы транзакции как удобно нам, а не СУБД, и просто взяли бы бесконечно мощный 1 сервер с любой реляционной СУБД.

Какие БД используют крупнейшие торговые сети для хранения заказов?

Saboteur, не так уж и бредово, NoSQL показали, что есть альтернативы, не универсальная замена, конечно, но сами реляционные модель и СУБД уже давно плохо применимы для нагруженных систем. Т.е. теоретически все прекрасно, на практике железо не вывозит. Никто уже строго не следует реляционной модели, наоборот каждый раз думаешь, где еще ее можно нарушить, чтобы разгрузить систему (те же json и т.п.). Что касается реляционных СУБД, для них всегда был стандартом ACID, но по факту никогда не выполнялся. Консистентность соблюдается только частично, внутри СУБД уже забили на foreign keys, а на уровне системы консистентности вообще нет в момент времени, из-за множества ДЦ. Изолированность только условная, потому что serializable напрочь убивает всю производительность. Атомарность присутствует номинально, просто потому, что мы вынуждены писать максимально короткие транзакции, а изза этого Устойчивость как бы существует, но далеко не всегда поможет, т.к. все реализовано в обход. OLTP и OLAP это не просто способы организации БД, это утверждение "либо так, либо так, вместе не умеем", поэтому когда нужна система совмещающая обе функциональности появляется огромное кол-во проблем и ограничений при ее реализации. Поэтому, на практике если и применяют реляционные СУБД для высокой нагрузки, то уж точно, не потому что они хороши.

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Александр Попов,

при существенном усложнении хранения и обработки

по этому поводу, более точно и подробнее Akina ответил.

Ну и в крайнем случае, мне проще в цикле применить mysql_real_escape_string() или аналог, ну или просто проэкранировать все одиночные кавычки в строках (не факт, что этого достаточно, но существуенно усложнит атаку).

Можно экранировать с помощью mysqli или PDO, и это будет примерно тоже, что и эмуляция подготовленных выражений в PDO. Просто экранировать кавычки очень ненадежное решение.
Решать вам, но нужно понимать риски подобных решений. Главное преимущество в защите от инъекций, это то, что подготовленные выражения разделяют код SQL и данные для него, и сервер не будет исполнять данные как код, теоретически это дает полную гарантию невозможности инъекций. С экранированием такой уверенности нет, что практика и подтверждает.

Как установить PHP в режиме отладки под Ubuntu?

Интерпретатор в консоли, и "в браузере", это совершенно разные программы, с разными конфигами, модулями и т.д.

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Александр Попов,

А вы не знаете, почему был выбран разработчиками такой принцип?

Если вы про то, почему PDO использует по-умолчанию эмуляцию, а не настоящие подготовленные запросы, то это не очень хорошая реализация в MySQL. Там при высокой нагрузке не всегда во время очищаются сохраненные подготовленные запросы. В том же PostgreSQL такой проблемы не было. Но, может в последних версиях и починили.
Что касается отсутствия поддержки множественных запросов с подготовленными выражениями, не скажу. Вероятно, малая вероятность повторного использования при существенном усложнении хранения и обработки, да и подготовленное выражение это уже 3 запроса вместо 1го, т.е. никто не видит проблемы в нескольких запросах к серверу.

Если один человек вводит, наверное он не станет вводить данные, которые могут привести к инъекции.

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

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Akina, да, его цель защита от sql-инъекций, а для этого надо прям заморочиться с парсингом. Но это речь только про эмуляцию.
Классический пример, баг PDO, когда в китайской кодировке использовался особый символ кавычки, который парсер PDO воспринимал как кавычку, а СУБД нет, или наоборот. В итоге, проходили sql-инъекции.

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Ипатьев,

Vitsliputsli, но PDO-то поддерживает. Так что пользователь PDO может продолжать использовать prepare.
Парсер в PDO вообще ни разу не полноценный, а простая заменялка плейсхолдеров. В том числе для обеспечения поддержки эмуляции.

Поддерживает, но автор использует эмуляцию.
Он для эмуляции и создан, для prepared он и не нужен, там уже СУБД сама разберется. Полноценный не в смысле, что он всю грамматику разбирает. Но он и не просто заменялка, так как на нем полноценная защита от sql-инъекций.

Почему возникает SQLSTATE[HY000]: General error: 2014 при прямой вставке данных в MySQL таблицы через DBAL?

Александр Попов, MySQL не поддерживает множественные запросы для подготовленных выражений:
https://dev.mysql.com/doc/c-api/8.0/en/c-api-multi...
https://dev.mysql.com/doc/refman/8.4/en/prepare.html
но вы попрежнему можете их использовать без подготовленных выражений.

Akina,

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

Что написано, то и передаётся серверу в том виде, в каком написано. Это его парсеру разбираться.

В библиотеке PDO уже присутствует полноценный парсер SQL. Мало того, по-умолчанию для MySQL именно он и работает (а так как в коде выше автор не отключал эмуляцию подготовленных выражений, то и в его случае тоже). MySQL плохо работает с prepared statements и вероятно поэтому PDO предпочитает их не использовать.

Memory limit в Clickhouse. Как бороться?

При попытке сделать к ней Left join или просто при выборке с сортировкой по какому-либо полю

Если просить вернуть все 200млн, то памяти скорее всего и не хватит.

Как получить имя переменной из строки?

Алексей Денисов, зачем кешу тратить время на чтение с диска? Каждый раз по 200 байт.

Вместо переменных и массивов - сделал отдельно файлы с именами 123, 578, 015 и т.д.
(на самом деле HEX значения - 6 знаков).
Имя = один из GET параметров запроса

Т.е. пользователь может посмотреть любой файл, имя которого укажет в GET параметре?

Как получить имя переменной из строки?

Алексей Денисов,

но в некоторых переменных содержатся строки более 2000 символов, а самих переменных может быть далеко за 100,
это какой массив тогда получится.

И что смущает? Массив получится такой как и должен. 200Кб это немного, а с переменными будет примерно те же 200Кб.
Для массивов данных в php есть структура массив, так почему ее не использовать?

Почему происходит откат изменений после выполнения merge request?

krosten92,

тоже думал, что форсит. Но утверждает, что нет

А зачем верить на слово? Откройте журнал git по ветке и проверьте, что действительно происходило, где был merge, а где rebase, или вообще reset.
Если что, это делается так:
git reflog show dev

Почему происходит откат изменений после выполнения merge request?

krosten92,

Я так понимаю ему ничего не пишется, а pull делать религия не позволяет

Это не религия, а банальная лень и наплевательство на чужой труд.
Скорее всего он делает force push, и тупо перезаписывает историю. Защитите ветку от force push или бейте по рукам.

Миграция с Виндовс на Арч. Какие могут быть проблемы?

Drno, логически это теоретически, у меня, на практике, LTS Ubuntu подсыпал неожиданные баги регулярно в отличии от Арча. Debian стабилен, но слишком древнее ПО для рабочего компа. Хотя на сервер я тоже постремался бы ставить роллинг релизы, почемуто верится, что все ПО в дистрибутиве лучше тестируется.
Арч ставится не намного сложнее, но нужно понимать, что делаешь. Поэтому и нет автоустановки, так сделано специально, если слишком сложно запустить несколько команд из консоли, то действительно не стоит его брать. Есть, конечно, всякие Manjaro, но чтото у их пользователей слишком часто возникают проблемы.

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

Т.е. скрипт находит новый файл, затем перезаписывает его, а значит скорее всего создает опять новый файл, и он опять попадает в скрипт как новый.

Знаю только Python и SQL. Нужно ли наращивать стек знаний перед попыткой смены работы?

paran0id,

kafka - вещь узкоспециальная, а вот kubernetes точно лишним не будет

kubernetes - вещь узкоспециальная, а вот kafka точно лишним не будет

Как составить SQL запрос для подставления значения по времени?

Задача видеть в каком статусе пришло то или иное сообщение

Значит вам нужна связь между статусами и сообщениями, в описанной схеме ее пока нет.

Как автоматически подставлять значение в value?

tajfun_rt, Если я правильно догадался, то вы хотите вывести id будущей записи, которая еще не записана в БД. Тогда укажите СУБД, какую используете. Если в ней есть отдельно вынесенный sequence, то пользуйтесь им. Если нет, то несколько вариантов, которые приходят в голову:
1) эмуляция sequence, т.е. прям в базе храните последний id (как вы и планировали), и при обращении высчитываете следующий и сохраняете (но нужно будет учитывать гонку);
2) каждый раз налету получать последний id (опять же гонка);
3) делать insert и использовать полученный id, а затем обогащать эту строку данными. Если допустимо по архитектуре и нет опасности большого кол-ва пустых строк, либо решите этот вопрос.