1. PHP / Говнокод #20148

    0

    1. 1
    2. 2
    3. 3
    4. 4
    5. 5
    6. 6
    7. 7
    8. 8
    9. 9
    public function getAllParentCategories($category_id,&$parents = array()) {
    	$parent_id = $this->db->query("SELECT parent_id FROM " . DB_PREFIX . "category WHERE category_id = '" . (int)$category_id . "'")->row['parent_id'];
    	if ($parent_id == 0)
    		return $parents;
    	else {
    		$parents[] = $parent_id;
    		return $this->getAllParentCategories($parent_id,$parents);
    	}
    }

    рекурсивная функция с sql запросом, что может быть лучше?

    Запостил: php73, 07 Июня 2016

    Комментарии (14) RSS

    • Обычная история, когда какое-нибудь дерево кладут в базу в виде "предок-потомок"
      Ответить
      • А потом при дереве страниц из 600 разделов это выливается жуткими тормозами. Для такого лучше вытаскивать все разделы и уже формировать дерево - будет работать в разы быстрее при больших объемах данных, но памяти будет жрать больше
        Ответить
        • для этого лучше взять субд с нормальными средствами иерархических запросов - это блядь не рокетсайнс, даже прости господи фаербёрд умеет в это

          но пыхобляди продолжают плакать и жрать свой вонючий мускул
          Ответить
          • ня:
            https://www.sitepoint.com/hierarchical-data-database-2/

            просто пыхобляди так не умеют
            Ответить
            • ты серьезно?

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

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

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

                а пыховцам от мускуля никуда нельзя
                у них без него вордпресс не запускается
                Ответить
                • > это просто такой способ хранить деревья в реляционках, оптимизированный на быстрое чтение.
                  теперь вставь ноду дочернюю, скажем, к Red, и получи удовольствие обновить значение rgt для всей таблицы

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

                  т.е. если на пальцах - хранить для записи id_path = '1/14/01/3', который и четко расскажет место в иерархии, и легко позволит поискать детей как тех, у которых их id_path начинается с '1/14/01/3/', саму же колонку правильно поиндексировать
                  Ответить
                  • зато можно получить слепок дерева одним запросом. Вот просто всех потомков, или всех родителей. Перестройка -- дело долгое, ясен пень, но не так уж часто структура меняется.
                    Ответить
                    • > зато можно получить слепок дерева одним запросом
                      И чо? В materialized path, про который Ди выше пишет, внезапно, тоже.
                      Ответить
          • Я покушать принёс:
            https://openquery.com.au/graph/doc

            OQGRAPH поставляется в коробке с MariaDB.
            Ответить
            • наверное, идея хорошая
              реализация, где у тебя принципиально разные вещи происходят, если ты для одного и того же запроса указываешь latch=0, latch=1, latch=2 вкупе с другими колонками или без или не указываешь - это какой-то маразм, неужто нельзя было функциями решить, ну или хотя бы имена
              Ответить
              • Вероятно, это было сделано для того, чтобы хранилище графов можно было джойнить с обычными таблицами. Дописать «лишнее» условие во WHERE никого не затруднит, зато во всех запросах всё те же колонки origid, destid, linkid.

                Могли бы сделать по-другому: вместо виртуального latch во WHERE множить таблицы (например, дописывая к имени таблицы суффикс 0, 1, 2). Но это уже как-то некрасиво.

                А как это решить функциями: DIJKSTRA(linkid), BREADFIRST(linkid) etc.?
                Ответить
              • Этот материал должен внести ясность, почему они так сделали:
                http://dev.mysql.com/doc/internals/en/custom-engine.html

                Они реализовали граф как плагин хранилища. Это позволяет перехватывать обращения к виртуальной таблице, но не позволяет вносить изменения в язык.
                Ответить
    • Нам нужно больше запросов!!!!1111
      Ответить

    Добавить комментарий