Есть таблица со стандартной иерархией id и parent_id Нужно получить все записи у которых больше двух подчиненных записи (детей) Код (Text): id | parent_id | data 1 | 0 | 2 | 1 | 3 | 1 | 4 | 1 | 5 | 2 | 6 | 2 | 7 | 3 | 8 | 3 | 9 | 3 | Нужно ОДНИМ SQL-запросом получить выборку в которой только 1 и 3
Код (Text): |1| |3| --- Добавлено --- Придумал решение, но не уверен, что оно оптимальное: Код (Text): SELECT parent_id, num FROM (SELECT parent_id,COUNT(*) AS num FROM `table` GROUP by parent_id) t WHERE num > 2
Не совсем понятно что имеется в виду под parent_id = 0 И в чем решение. Оно дает на выходе все ветки?
то что у id1 нет родителя Все записи у которых больше двух подчиненных записи (детей), в данном примере это записи c ID1 и ID3
Понятно. Нормальное решение. Смутила parent_id, это немного из другой оперы. Но, название можете, конечно, давать любое.
Решение нормальное. Можно ещё использовать HAVING Код (SQL): SELECT parent_id, COUNT(*) AS num FROM `table` GROUP BY parent_id HAVING COUNT(*) > 2
Для вывода многоуровневых категорий(например разделов магазинов, или жанров библиотек) лучше использовать json, или xml. А то и txt. Перезаписывая их только при изменении структуры.
Я не понимаю таких радикальных заявлений. Бывают случаи, когда осознанная денормализация выгодна. Но просто заявить "да ну нафиг вашу реляционную БД, json решает всё" - это несеръёзно. Где обоснование?
А для езды на мотоцикле лучше использовать шлем. Внимательно прочитайте, что нужно ТСу, и больше не оффтопьте. --- Добавлено --- Это именно из этой оперы. Список смежности (список смежных вершин) называется, если не в курсе.
Элементарно. Список понятен "невооруженным" взглядом. И может быть отредактирован рядовым менеджером по продажам. В любой, самый неудобный момент. Не совсем. Вывод такого списка из нескольких десятков, сотен тысяч смежностей (например книжные серии с зависимостями) не то же самое, что вывести два десятка разделов интернет-магазина. --- Добавлено --- Раздражаю?
Если на то пошло, менеджеру неудобно редактировать JSON Это дело программистов и дизайнеров как представить структуру на фронте, скрывая технические детали от пользователя.
Я согласен, что вопрос спорный, но и не вижу преимуществ вашей точки зрения. На этом и предлагаю закруглить.
Если бы это была моя т.з., а то это обычный подход для бекенда с реляционной БД. "Для вывода ... лучше..." это подход фронтедера. Загруглиться можно на том, что API может использовать JSON. Глубже фронтендеру лезть не надо.