Как получить 3 массива из одного запроса?

Question

[vardz]

Есть mysql таблица, в которой всего 2 поля user и status. user-ов будет не более 150, а status-ов всего 3 со значениями 0, 1 или 9
примерный вид
user status
name1 0
name6 0
name9 0
name2 1
name5 1
name6 1
name7 9
name8 9
name3 9

Хотелось бы понять, как вместо 3 запросов к бд вида

SELECT user, status FROM `user_status` WHERE status = "0"
SELECT user, status FROM `user_status` WHERE status = "1"
SELECT user, status FROM `user_status` WHERE status = "9"

сделать один запрос вида
Насколько я понимаю, 1 запросом
$result = mysqli_query($conn, "SELECT user, status FROM user_status");
и потом выхлоп привести к 3 простым массивам в php вида

$user_status_0_array = ["name1", "name6", "name9"];
$user_status_1_array = ["name2", "name5", "name6"];
$user_status_9_array = ["name7", "name8", "name3"];

p.s. php8x

Comments

[Akina]

GROUP BY status

[Михаил Ливач]

вот как раз GROUP BY тут неуместен

[Akina]

Михаил Ливач, не обоснуете ли своё утверждение? Не забывайте - у автора MySQL, а результат будет обрабатывать PHP.

[Михаил Ливач]

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

[Akina]

Михаил Ливач, Я написАл ответ, где рассказано, как будет использована группировка.

Answer 1

[Everything_is_bad]

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

Answer 2

[Akina]

На стороне MySQL (при необходимости - скорректировать @@group_concat_max_len):

SELECT status, GROUP_CONCAT(user) userlist
FROM user_status
GROUP BY status

На стороне PHP (синтаксиса не знаю, схематично):

if $row['status'] = 1 then $user_status_1_array=split_to_array($row['userlist'])

Comments

[Adamos]

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

[Akina]

Adamos, Хорошо, допустим, что экономия трафика нам некритична. Но давайте подумаем, что должен сделать PHP в моём коде и в коде по шаблону, показанному Михаилом.

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

В случае получения CSV-списка PHP всего-то должен преобразовать его в массив. Я посмотрел - это функция explode(). Не знаю, что у неё в потрохах, и как именно она создаёт массив, но с точки зрения скорости она бы должна в один проход определять начала и длины элементов, потом сразу создавать массив нужного размера и выполнять копирование по имеющимся ссылкам.

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

лишняя работа по склеиванию/разделению

На стороне MySQL накопление результата в CSV - это не работа. Элементарно построение плана, и то займёт больше времени. На стороне PHP, как я уже сказал, я не могу адекватно проанализировать разницу.

шанс упереться в упомянутые ограничения

Если кто-то не настроил соединение так, чтобы НЕ упираться у упомянутые ограничения - это недостаток НЕ метода.

невозможность пагинации

А зачем нужна пагинация при сохранении в массив, скажите вы мне...

потенциальные грабли при изменении задач

o_O Вот вообще не понял, о чём речь...

в чем достоинства такой конструкции перед банальным запросом и разбором в пыхе?

Вообще MySQL более эффективно обрабатывает массивы однородных данных - его для этого и создали, он на это заточен.

PS. Если товарищу нужно регулярно получать такие данные, я бы вообще предложил ему повесить на таблицу триггер и накапливать в удобном для быстрого получения формате агрегированные предрасчётные данные в дополнительной таблице. Но он получает их в PHP, который не умеет принимать значения поля записи сразу в массив, так что в данном конкретном случае это неприменимо.

[Adamos]

Akina, спасибо за мнение. Я, напротив, более уверен в РНР, а вот насчет БД предпочитаю сразу считать, что юзеров миллионы, и строчка получится непредусмотренной длины. Такой подход позволяет писать, не вникая в тонкости настройки БД :)

[Akina]

Adamos,

насчет БД предпочитаю сразу считать, что юзеров миллионы, и строчка получится непредусмотренной длины.

В общем случае согласен. Но сейчас-то мы имеет дело с конкретным вопросом, а автор чётко прописывает, что

user-ов будет не более 150, а status-ов всего 3 со значениями 0, 1 или 9

Даже хочется его дополнительно спросить - если у тебя статусы чётко заранее обозначены, и один юзер может иметь несколько разных, то почему ты не используешь SET?

Я, напротив, более уверен в РНР

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

[Михаил Ливач]

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

Как вы сами ниже отметили слова автора:

user-ов будет не более 150, а status-ов всего 3 со значениями 0, 1 или 9

Так что, даже если explode() и устроена так оптимально, как вы предполагаете, это всё экономия на спичках в ущерб читабельности. Олимпиадное программирование.

Мой комментарий о вредности GROUP BY появился потому, что о GROUP_CONCAT вы там не упомянули. А применение одного GROUP BY к тому запросу даст совершенно другой результат. Поскольку топикстартер начинающий, ему бы это только повредило. ( Кстати, я про GROUP_CONCAT тоже не подумал). Если vardz вдруг прочитает эту ветку, то я имею в виду запрос

SELECT user, status FROM `user_status` GROUP BY status

Если не ошибаюсь, это специфика MySQL, что такой запрос вообще отрабатывает, и результат на выходе - тоже специфика MySQL.

Я сторонник того, что инструмент нужно применять для того, для чего он предназначен. Группировка не этого.
Ну и посмотрим на это с другой стороны: а если у нас имя пользователя - это какой-нибудь "Иванов, Виктор Петрович" ( я понимаю, что тогда разумнее было бы назвать поле fio - но на практике кучу раз встречал name или user)? И вообще, делать SQL запрос зависимым от данных, с которыми он работает - "вот тут у нас есть запятые в данных, поэтому так, а вот тут нету, поэтому эдак" - это лишнее усложнение системы.

[Akina]

Михаил Ливач,

Если не ошибаюсь, это специфика MySQL, что такой запрос вообще отрабатывает, и результат на выходе - тоже специфика MySQL.

В MySQL 8+ с настройками по умолчанию такой запрос приведёт к ошибке. Да, можно "уговорить" MySQL любой версии выполнить такой запрос, для этого нужно просто включить ONLY_FULL_GROUP_BY в Server SQL Mode. Но если покопаться, то это не специфика MySQL, это просто скрытое от глаз пользователя и применяемое по умолчанию (тогда как другие СУБД требуют явного указания) использование агрегатной функции ANY_VALUE().

Я сторонник того, что инструмент нужно применять для того, для чего он предназначен. Группировка не этого.

Формально согласен. Но посмотрите на используемый автором подход. Он желает получить список для каждого статуса в ОТДЕЛЬНОМ массиве. Ну и что это, как не группировка? То есть разделение на отдельные независимые группы по некоему признаку. Отсюда и мой ответ.
Вот получал бы он всё в один двумерный массив - да, группировка была бы не к месту. И в принципе это было бы более логичным решением - как раз тут могла сыграть свою роль неопытность товарища. Но на стороне PHP я его поправить не могу, не моя область. Я в нём сам, если припрёт, такое пишу, что легко доведёт опытного разработчика до инфаркта - так что хрена с два я кому что покажу...

делать SQL запрос зависимым от данных, с которыми он работает - "вот тут у нас есть запятые в данных, поэтому так, а вот тут нету, поэтому эдак" - это лишнее усложнение системы.

Вот тут, признаться, не понял. GROUP_CONCAT, если не указать явно, будет безусловно использовать в качестве разделителя запятую. Посему его без указания разделителя используют лишь там, где данные в принципе неспособны включать в себя запятую. Иначе необходимо переопределять разделитель (я предпочитаю это делать безусловно, и мой любимый разделитель CHAR(0), ибо в строковых данных его с огнём не сыскать).

[Михаил Ливач]

это просто скрытое от глаз пользователя и применяемое по умолчанию (тогда как другие СУБД требуют явного указания) использование

это и называется специфика :)

Вот получал бы он всё в один двумерный массив - да, группировка была бы не к месту.

а в чём разница? Двумерный ( а вообще, любой N-мерный, где N >=2) массив - это просто массив массивов ( по крайней мере, в PHP так ).

GROUP_CONCAT, если не указать явно, будет безусловно

Смотрите, какая история получается: нужно удерживать в голове кучу каких-то нюансов. Согласен, в частном случае это выглядит удобно, но если смотреть в целом, то читабельность и понятность кода падают.
Приведу близкий мне пример: в Битриксе есть статический метод CIBlockElement::getList(), который обычно возвращает объект результата. Однако, если в качестве необязательного параметра передать пустой массив, то метод вернет не объект, а просто число записей.
И вот теперь приходится помнить, что есть такое поведение.

[Akina]

Михаил Ливач,

это и называется специфика
нужно удерживать в голове кучу каких-то нюансов

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

а в чём разница?

В том, какой уровень агрегации запрашивается. Дать имена по отдельности - это один уровень, дать имена слитной группой - совсем другой. Только не путаем с сортировкой.

[Михаил Ливач]

Akina, судя по всему, у нас разный взгляд на вещи. Вы вот даже для двумерного массива вводите свою специфику использования, и вас не напрягает. Меня напрягает.
Когда-то давно у меня было два старших коллеги. И в той компании было принято время от времени собираться всей толпой разработчиков, обмениваться опытом. (Я не пишу "командой", так как команд там не было). И вот интересная штука: когда первый из старших демонстрировал свои наработки, было понятно, как это перенести на другие проекты и в каких случаях оно может пригодиться. Не было специфики.
А второй тоже показывал вроде бы прикольную штуку, но она были настолько намертво приклеена к тому проекту, на котором он её реализовал, что попытка применить её на другом проекте превращалась в чудовищную проблему. Всё было очень, очень специфично.
Наверное, с тех пор у меня такое отношение.

Answer 3

[Михаил Ливач]

да, правильно мыслите - в цикле, который будет построчно обрабатывать $result, проверяете и добавляете в нужный массив:

while ($row = $result->fetch_assoc()) {
    switch( $row['status'] ) {
         // тут кейсы
    }
}

Когда заработает, подумайте вот о чем:
1) зачем вам такие длинные и неинформативные имена вроде $user_status_0_array? То, что это массив, подскажет IDE.
2) нужно ли тут три массива, или лучше использовать один многоуровневый?

$users = [
   0 => ["name1", "name6", "name9"],
   1 => ["name2", "name5", "name6"],
   2 => ["name7", "name8", "name3"],
];

Answer 4

[vardz]

вроде вот так получилось

$user_status_0_array = [];
$user_status_1_array = [];
$user_status_9_array = [];

mysqli_report(MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT);
$user_status_result  = $conn->query("SELECT users, status FROM user_status");
while ($row = $user_status_result->fetch_assoc()) {
    if ($row['status'] == '0') { $user_status_0_array[] = $row['users']; }
    if ($row['status'] == '1') { $user_status_1_array[] = $row['users']; }
    if ($row['status'] == '9') { $user_status_9_array[] = $row['users']; }
}

print_r($user_status_0_array);

if (in_array("name2", $user_status_0_array)) {
        echo "YES";
    } else {
     echo "NO";
    }

Михаил, Акина.. спасибо большое
p.s. неинформативные имена вроде $user_status_0_array - это я так назвал, чтоб тут понятней было =)

Comments

[Everything_is_bad]

какой же всё таки это трэш

Акина.. спасибо большое

ты его прочитал, но ничего не понял и сделал самое плохое решение, на собезах, твое резюме сразу выбросят, а контакт в блоклист добавят

[Akina]

Полностью согласен с предыдущим оратором. Раскладывать однородные данные, фактически экземпляры одной и той же сущности, в разные корзины - это плохая идея. Обратите самое пристальное внимание на ответ Михаила, особенно на его слова

нужно ли тут три массива, или лучше использовать один многоуровневый?

Answer 5

[Денис Митрофанов]

Выполните запрос без условий и итерируйте результат, используя значение статуса как ключ для динамического формирования подмассивов. В цикле while через fetch_assoc добавляйте имя пользователя в массив вида $data[$row['status']][], что автоматически сгруппирует их по категориям. После завершения цикла вы получите структурированный массив, где элементы доступны по индексам 0, 1 и 9 без лишних обращений к СУБД.