Хранение иерархических данных в плоском виде

    На примере хранения дерева комментариев.

    Многие наверняка сталкивались с проблемой хранения комментариев, по крайней мере задумывались об этом. Очевидным решением «в лоб» является ссылка на родительский комментарий и, как следствие, рекурсивные вызовы при необходимости отобразить дерево. Современные СУБД поддерживают иерархические запросы, но мне кажется, что это просто перенос проблемы за пределы области видимости, может быть я не прав. В любом случае я писал для Google Application Engine, там разговора об иерархических запросах не идёт вообще.

    Мне очень не нравилась перспектива рекурсии и множество мелких запросов к базе, поэтому я стал изобретать какой-то способ получить все комментарии одним простым запросом. И такой способ я довольно быстро «изобрёл». Опросил нескольких знакомых, оказалось, что мало кто на эту тему задумывался, поэтому возьму на себя смелость описать что именно я реализовал.



    Итак, главное требование — получить все комментарии сразу в нужном порядке одним запросом. Соответственно, я должен хранить 1) порядок отображения 2) уровень вложенности.

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

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

    Ниже небольшое дерево комментариев с примерами хэша.

      000000   1 первый комментарий
      000100     1.1 ответ на первый комментарий
      000101       1.1.1 ...
      000102       1.1.2 ...
      000103       1.1.3 ...
      000104       1.1.4 ...
      000200     1.2
      000300     1.3
      010000   2 второй комментарий
      010100     2.1 ответ на второй комментарий
      010200     2.2 ...
      020000   3 третий комментарий


    Здесь числа типа «1.1.х» это просто часть комментария, а не часть хэша, каким его предлагает классический «материализованный путь».

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

    Автоматически следуют два ограничения:
        1) ограничено количество комментариев на каждом уровне
        2) ограничено количество уровней.

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

    В действительности я решил что на оба эти ограничения можно закрыть глаза. В случае хранения комментариев и их количество и вложенность вполне можно ограничить. Кроме того я пошёл на небольшую хитрость и «разрешаю» добавлять комментарий на 4-й уровень, но фактически оформляю это как комментарий третьего уровня и так же отображаю. Это сделано чтобы не ограничивать обсуждение двух увлёкшихся комментаторов.

    Подробности реализации
    Развивая эту идею, от цифрового поля я решил отказаться в пользу текстового. В этом случае я немного теряю в эффективности, но зато я вообще не ограничен в длине хэша. Вместо цифр я пользуюсь символами A-Z и a-x, то есть фактически использую числа с основанием 50 (пятидяситеричная система).

    В пятидесятиричной системе я одним разрядом нумерую сразу 50 записей, двумя — уже 2500, для моих целей этого достаточно. Уровней вложенности я использую 8. Оба эти параметра легко меняются, но это можно сделать только один раз, перед началом использования.

    С целью вычисления хэша для каждой записи кроме её уровня вложенности я храню ещё и количество дочерних записей, чтобы при добавлении очередной записи не приходилось делать лишних запросов (google data storage, фактически, не умеет выполнять select count(*)).

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

    Кстати, просто на всякий случай, я храню ссылку на родительский элемент. Если я вдруг решу всё поменять — у меня будут все исходные данные для восстановления картины.

    Выводы
    легкий дискомфорт из-за всё-таки наличия ограничений;
    некоторые сложности при вычислении этого служебного поля;
    моментальная выдача всех результатов одним плоским запросом без лишней нагрузки на сервер.

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

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

    P.S. Ах да, если кто-то подскажет классические названия или реализации решения этой задачи, будет здорово.
    Share post
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 110

      0
      Неплохо. Надо испробовать у себя…
        0
        В IBM (и не только ibm и ms тоже было замечено) иерархию реализовали так

        path id, id1, id2, id3…

        Очень легко и просто, единственный недостаток — избыточность данных, хотя не особо она избыточна, если присмотреться, зато плюсов очень много. Первое — скорость, вторая легкость, равномерность нагрузки и еще куча вкусностей.
        И уже все давно реализовано, причем в полностью законченных видах.
        +7
        А по-моему это ограниченный MPTT, нет?
        И пример в лоб
          0
          по-моему это parent path, немного мутированный… надо покопаться…
            0
            Про пример в лоб- если добавить к cherry потомка надо будет изменить данные для 11 элементов? Для холиваров в комментах такая система будет несколько накладной)
              0
              Почитал и понял, что так и есть. Я сам его использую: четыре разряда на уровень = до 10000 элементов, быстрые выборки и элементарный доступ к родителям. Как-то приятнее оно мне MPath
              +9
                +5
                Хороший способ реализации, но если приходится ковырять данные вручную, часто возникает желание застрелиться. Ещё из минусов — добавление 1 узла может привести к обновлению всех узлов в дереве.
                  +4
                  Да, штука очень своеобразная. На самом деле в неизменном виде довольно мало применимая, на мой взгляд. Nested Intrvals лучше, но тоже на любителя.

                  Кстати, вот пачка слайдов по деревьям. Когда-то на хабре проскакивала. Позволяет быстро ознакомится с основными концепциями.
                  0
                  Идеально для чтения, фигово для добавления. Хотя можно сюда же, к Left/Right, добавить классическое id/pid и будет самое оно. Обновлять данные L/R по job'у
                    0
                    Большой недостаток — безопастность данных, затраты на перерасчет.
                    Лучше id, id1, id2, id3
                    +1
                    Отчего бы тогда не сделать восемь полей? Будет значительно быстрее и проще.

                    А комментаторы восьмого уровня будут неоспоримыми by design :)
                      0
                      Сложнее структура и её каждый раз придётся менять. Ну и запросы типа order by f1, f2, f3, f4, f5… мне тоже не очень нравятся. Зато нет ограничения на разрядность на каждом из уровней.
                        0
                        Сортировать можно только по одному полю, по нему GAE автоматически создает индекс.
                      +7
                      Мне очень не нравилась перспектива рекурсии и множество мелких запросов к базе
                      Вполне адекватный вариант — когда одним нормальным запросом выбираются все комментарии, а сортировка в нужном порядке делается рекурсией, или даже циклом (рекурсия тут в цикл легко разворачивается). В таком виде это не будет иметь ограничений на уровни и кол-во комментариев на них.
                      Вы не для free-lance.ru писали?:) Там тоже уровни комментариев ограничены, из-за чего при длительном обсуждении начинается каша и непонятно кто кому отвечает. Очень неудобно на практике.
                        0
                        Ну мне хотелось именно выгребать в готовом виде всё сразу из базы, такая идея фикс.

                        Нет, я писал для своего блога на GAE, что-то там пока больше двух ответов редко бывает :)

                        Много ответов всегда сложно читать, вариант который предлагает тот же lj ещё хуже, например.
                          +1
                          >Ну мне хотелось именно выгребать в готовом виде всё сразу из базы
                          >там пока больше двух ответов редко бывает :)

                          а зачем тогда вообще хранить комментарии отдельными экземплярами модели и их как-то искать?
                            0
                            Ну вариант — посмотреть все комментарии юзера.
                              0
                              это sql головного мозга — придумывать ненужные кейсы на «а вдруг»
                                0
                                Зачем придумывать — смотрю хабр и вижу эту функциональность. Иногда ею пользуюсь.
                            0
                            А использовать хранимые процедуры не пробовали?
                              +1
                              Во-первых в GAE нет хранимых процедур.

                              Во-вторых идея была именно хранить данные так, чтобы их можно было одним простым запросом извлечь и оформив отобразить, без обработки.
                                0
                                Спасибо за статью — довольно мало полезной информации о деревьях в применении GAE.
                                О «кешировании» не думали? Например:
                                при появлении комментария добавлять Задачу в очередь на рендеринг (время жизни Тасков выше, чем обычных запросов) и уже это запихивать в базу
                            0
                            буквально на прошлой неделе реализовывал хранение комментариев и их вывод, точно так и сделал, думаю самый оптимальный вариант, никаких ограничений, все просто и логично
                            +1
                            Как вариант можно иметь два поля, одно позволяет сортировать по уровням, а второе — по-порядку. Тогда ограничение на количество комментариев на одном уровне снимается.
                              +1
                              А как вычислять то поле которое «по порядку»? У меня вот для него этот хэш и есть, вроде бы. Из него на самом деле видно и уровень, но я его в явном виде ещё храню, чтобы не делать лишних «вычислений».
                                +1
                                Да, вы правы — так не получится. При вставке нового комментария придется переписывать всю таблицу.
                                  0
                                  Рискну предложить еще одну идею — создать по колонке на каждый уровень комментариев. Их содержимое, фактически, будет соответствовать нумерации «1., 1.1., 1.2., и т.п.».
                                  +1
                                  Комментарии добавлять хранимой процедурой.
                                  Перед добавлением вычислять два поля: уровень (определяется как уровень родителя + 1) и порядок (вычисляется как максимальный порядок комментария того же родителя + 1).
                                  Вопрос целостности данных, конечно, придется решать дополнительными средствами.
                                    0
                                    Нет в GAE хранимых процедур.
                                    А смысл? Все-равно при этом надо будет обрабатывать всю выборку, чтобы показать в верном порядке
                                    +1
                                    уровень хранить в отдельном поле, порядок — дата/время создания записи
                                  0
                                  приходила в голову подобная идея. до реализации дело не дошло, но концепция та же. даже больше того приходило в голову несколько идей, как с дополнительным полем, которое фактически может выполнять функцию и первичного ключа, в котором хранится некоторая информация по порядку вложенности элемента.

                                  опять же зависит и от сумой СУБД, так как в Oracle, к примеру, можно реализовать через систему вложенных таблиц, или те хе объекты в полях таблиц. на самом деле все зависит от средств разработки. можно в пустую при каждом комментарии индексировать все дерево комментариев на предмет правильно постановки, а уже выдачу вести из этого индекса.
                                    0
                                    Правильно ли я понимаю, что вам это нужно для того, чтобы выдергивать произвольные ветки обсуждения, для подгрузки аяксом? Ибо если комментарии отображаются все сразу — не вижу преимуществ перед следующей схемой:
                                    Храним идентификатор комментируемой сущности, идентификатор комментария (AI), идентификатор родителя (0 для комментариев первого уровня).
                                    Для получения всех комментариев к записи выбираем по идентификатору сущности, потом в цикле строим дерево ($comments[$currentComment['parentId']]['childs'][] = &$currentComment;) и отдельный массив со ссылками на комментарии первого уровня. Вам в этом смысле чуть проще разбирать дерево, но запрос будет сложнее. Я не прав?
                                      0
                                      Идеи доставать отдельно ветки не было (хотя можно это сделать, нужно будет делать запрос с двумя условиями по хешу).

                                      Строить дерево на клиенте… ну фиг знает, что-то в этом есть порочное ;)
                                        0
                                        На клиенте? В смысле на сервере, который клиент мускуля?
                                        Ну вы же тоже будете строить дерево, разве нет? По мне
                                          0
                                          Прощу
                                            0
                                            Да е-мое! Прошу прощения.
                                              0
                                              Я зачем-то жму Ctrl-enter и промахиваюсь мимо бекспейса. Простите ради бога.
                                              Так вот. По мне — лучше нагрузить application-сервер, чем сервер баз данных. А если вы хотите получать комментарии сразу в том порядке, в котором они должны идти, избавляясь от необходимости строить дерево — тогда да, соглашусь, nested sets еще хуже, если нет задачи постоянно тягать ветки)
                                                0
                                                Да, «задача» была именно такая. Хотя совершенно не факт, что это экономически наиболее эффективный путь, так как на вычисление этих хешей я тоже что-то трачу ведь.
                                                  0
                                                  Ну тут вопрос активности обсуждения. Если просмотров больше чем добавления комментариев — ваш путь быстрее все-таки)
                                                    0
                                                    Кстати, я понял. Вы фактически используете те же самые nested sets, только с большииим запасом. Поскольку вам наплевать на пересечение диапазонов комментариев первого уровня («отступ» вы все равно храните) — вы можете делать тот же самый запас на nested sets, и выиграть в скорости за счет сортировки по числовому, а не текстовому полю.
                                              +1
                                              Ну да, на клиенте, который http-сервер. GAE за лишние вычисления будет лишние ресурсы процессора начислять.

                                              Я дерево как бы не строю, я тупо показываю всё отсортированным по хешу с отступом равным полю «отступ», дерева как бы и нет, только в виде абстракции и резервных ссылок на родителей.
                                                0
                                                Да, я понял, спасибо) Я видимо был невнимателен к преамбуле и в целом туплю сегодня сильно)
                                            0
                                            для выдёргивания отдельных веток весьма эффективно хранить список всех предков просто в списочном проперти, и выбирать всех потомков охапкой Query(Comment).filter('ancestors =', top)
                                              +1
                                              Это да. Я вообще в последнее время от фундаментализма нормализации склоняюсь к денормализации, заметно упрощает жизнь. Ну в разумных, конечно, пределах.
                                                +1
                                                к датасторе нормализация не особо применима — оно не реляционное нифига.
                                                  0
                                                  Ну я немного в курсе, но лишние данные дублировать не очень люблю, хоть и нереляционное. И в реляционных, с которыми иногда работаю стал немножко денормализовывать по-тихому, пока студенты не видят.
                                                    0
                                                    Если рассматривать её в «бытовом» смысле слова (исключение дублирования данных и т. п.), то вполне применима.
                                              +2
                                              Таки речь идет о «материализованном пути», в бинарном представлении.
                                                0
                                                О, видимо да. Некоторая модификация и, по-моему, не бинарное представление.

                                                Всегда приятно самому изобрести действующий велик!
                                                  0
                                                  Работающий вел — это на котором можно неспеша лисапедить, а не жостко педалить) В данном случае он как не очень масштабируется на произвольное количество камментов)
                                                    0
                                                    А покажите мне блог, где больше 2500 комментариев? И я соглашусь сделать трёхразрядными счётчики, придётся исправить ровно один символ в дефайнах.
                                                      0
                                                      Тут два ограничения:
                                                      1. достаточно переполнить один уровень ирархии — обычное дело, когда комментарии вырождаются в проский набор, для этого алгоритма;
                                                      2. глубина рекурсии в данном примере ограничена тремя — это жесть с точки зрения любого уважающего себя троля.
                                                        0
                                                        Попробуйте что ли прочитать текст статьи?
                                                          0
                                                          пробовал, там несколько вариантов изложено — а память запомнает лишь самое доступное)

                                                          Вот как понять, вы сперва пишете: «все хранится на третьем уровне — и четвертый, и пятый, и десятый».

                                                          И тут же «Развивая эту идею, от цифрового поля я решил отказаться в пользу текстового» — но тут ведь нет явного отрицания уже сказанного. И вообще труЪ-программисты предложения содержащие «тут есть одна хитрость» и все рядом с ним не читают даже по диагонали)
                                                        0
                                                        такие количества комментариев вполне бывают сами знаете у кого.
                                                        раз в месяц, кажется.
                                                          0
                                                          А покажите мне блог, где больше 2500 комментариев?
                                                          goo.gl/31LFg примерно 2520 :)
                                                    +3
                                                    ваш метод называется materialized path
                                                      0
                                                      Не совсем. Чуть подправил текст, чтобы было лучше понятно что именно я предлагаю.
                                                        +1
                                                        Не вижу никаких существенных отличий.
                                                          0
                                                          отсутствие точки?
                                                        +4
                                                          0
                                                          CONNECT BY в Oracle, если не ошибаюсь, самое оно.
                                                            0
                                                            да, там главное ORDER SIBLINGS BY не забыть :)
                                                            Но в статье речь о системах, где нету ничего, похожего на это.
                                                            +1
                                                            Как то так:

                                                            ...
                                                            00101 1.1.1 (подкомментарий №1)
                                                            ...
                                                            00199 1.1.99 (подкомментарий №99)

                                                            А с подкомментария №100 начинается веселье.
                                                              +1
                                                              Скажите, а чем и почему ограничено количество уровней?
                                                                0
                                                                Ой.

                                                                Плохо соображаю под конец дня, но кажется вы очень толковый вопрос задали, спасибо. Непременно отчитаюсь отдельно об этом.
                                                                  0
                                                                  В общем начиналось всё с числового этого «пути», то есть были бы пути в духе тех, что я написал в примере 010000 и подобные. Чтобы работала сортировка, я, конечно, должен добивать нумерацию на нулевом уровне нулями на младших разрядах, чтобы 02 не оказалась раньше 010101, например.

                                                                  Так как длина числа ограничена и это всего 10 значений на знакоместо, я перешёл на буквы, то есть та самая система счисления с основанием 50. Но буквы сортируются не по значению, а алфавитно и получается что добивать нулевыми разрядами ничего не надо, то есть ac всегда будет идти после ababab, например.

                                                                  Вложенность остаётся ограниченной просто длиной текстового поля отведённого под этот хеш, вот. Надо попробовать проверить этот вариант на практике, чего лишние буквы хранить.
                                                                    0
                                                                    Это очень ценное наблюдение — по сути оно снимает ограничение на количество уровней.
                                                                  +2
                                                                  В постгресе есть замечательные запросы WITH RECURSIVE которые позволяют выгребать рекурсивно деревья.
                                                                  Вот красивая статейка на эту тему — explainextended.com/2009/09/24/adjacency-list-vs-nested-sets-postgresql/
                                                                    0
                                                                    Да есть вообще ltree для работы с деревьями.
                                                                    +1
                                                                    а нафига на GAE так танцевать? храним все комментарии в одном entity в пикле и не чешемся вообще.
                                                                      0
                                                                      В GAE есть ограничение в 1 мегабайт на одну запись.
                                                                        0
                                                                        при мегабайте комментариев и смотреть эту простыню будет адово.
                                                                      0
                                                                      можно принтскрин графиков нагрузки с админки?
                                                                        0
                                                                        А там ничего особенно интересного, про нагрузку я отдельно писал, там и графиков побольше.

                                                                        Сейчас нагрузка по заходам меньше чем в тот раз была.
                                                                        +1
                                                                        Зачем так усложнять? Почему нельзя просто выбрать одним запросом все комметраии, и вывести их одним циклом?
                                                                          0
                                                                          Без вложенности? Так сначала и было, очень неудобно.
                                                                            0
                                                                            С вложенностью
                                                                              0
                                                                              Идти по комментариям и присоединять очередной комментарий к его родителю.
                                                                                0
                                                                                перед эти отсортировав их по (parent, position)
                                                                            0
                                                                            Traceback (most recent call last):
                                                                            File "/base/python_runtime/python_lib/versions/1/google/appengine/ext/webapp/__init__.py", line 702, in __call__
                                                                            handler.post(*groups)
                                                                            File "/base/data/home/apps/dgwnpgnd/1.350986457899533822/comment.py", line 491, in post
                                                                            text = process_comment(self.request, True)
                                                                            File "/base/data/home/apps/dgwnpgnd/1.350986457899533822/comment.py", line 569, in process_comment
                                                                            bgrec = basecmnt.blogrec
                                                                            AttributeError: 'NoneType' object has no attribute 'blogrec'

                                                                            что-то у вас сломалось…
                                                                              0
                                                                              закатил обновление, строим индекс ;)
                                                                              +2
                                                                              Посоветуйте, как разбивать вложенные комментарии на страницы (комментариев в теме бывает более 500 и выводить их на одной странице — убийственно просто).
                                                                                0
                                                                                В моём случае как раз решается легко: по порядку, плюс аяксом подгружать вниз. То есть вот select from comments where blogpost = :1, order by hash, limit 500. В случае с GAE правда будет небольшой косяк с limit 500 (он не умеет), но обходится легко как раз с помощью монотонно растущего hash.
                                                                                  0
                                                                                  Хм… а если страница вторая и комментариев более второго уровня больше, чем 500, среди которых есть и новые и старые. И таких тем 50-60. Как бы Вы отобразили это, чтобы пользователю было понятно, где он находится и к чему каждый комментарий?
                                                                                    +1
                                                                                    когда комментариев второго уровня больше чем страница, пользователю-читателю уже пофиг.
                                                                                    а пользователи-писатели и так разберутся, по ссылкам в имэйл-уведомлениях :)
                                                                                      0
                                                                                      Для начала я бы давал «листать» аяксом, продолжая вниз, не потеряешься. Проблемы найти комментарий первого уровня для любого заданного дочернего нет, это будет комментарий с хэшем с обнулённым хвостом, можно начинать страницу всегда с таких. Это всё довольно легко решается при таком подходе по-моему.
                                                                                  0
                                                                                  а исходники livejournal, например, случайно не opensource?
                                                                                    0
                                                                                    В lj одна из самых медленных и некрасивых реализаций комментариев, уж я не знаю что причиной, миллиарды комментаторов или таки кто-то пытался решать проблему «в лоб». Кстати у них ещё и какое-то смешное ограничение на количество комментариев к одному посту есть.
                                                                                      0
                                                                                      а чем оно некрасиво?
                                                                                        +2
                                                                                        Чисто внешне: что ли можно это читать? Всего 200 комментариев, а превратилось в целый квест.
                                                                                          0
                                                                                          а что там не так?
                                                                                          — пэйджатся камменты первого уровня (чтобы на странице не оставался только хвост)
                                                                                          — длинные ветки сворачиваются.
                                                                                          чем вам это кажется ужасным и какие альтернативные формы выдачи флэймов на ваш взгляд более удобны?

                                                                                          я бы, конечно, глубину сворачивания чуть побольше сделал, чтобы тема углубления очевиднее была.
                                                                                          ну и подгружал/скрывал бы их аяксом, также как и сами страницы.

                                                                                            +2
                                                                                            Читать комментарии когда начались сворачивания просто вообще нельзя. Это и не нравится, никто и не читает. Expand этот клёвая штука, но медленный до ужаса.

                                                                                            Мне куда больше нравятся варианты хабра и лепры/дёти, надо думать и то и другое футурико основали, так и остаётся. И там (на лепре) бывает за тысячу комментариев, ну тяжеловато открывается, да… Можно придумывать страницы; самое соблазнительное, конечно, — нарезать по комментариям первого уровня. Причём GAE как раз будет мотивировать ограничивать не по комментариям первого уровня.

                                                                                            Кстати бесконечная вложенность, именно визуальная, приводит к комментариям шириной в 50 точек на хабре — не лучший вариант. Это была одна из идей, из которых я исходил вообще — ограничить вложенность по крайней мере визуально.
                                                                                    0
                                                                                    Я также такой способ использовал для хранения комментариев, только для хранения хеша использовал поле blob, и все ASCII символы, тогда один байт мог содержать 256 позиций, 2 байта — 65536, и так дальше…
                                                                                      0
                                                                                      В хранилище GAE хранение дерева «из коробки» и все комменты к посту выбираются выборкой этого поста. Или есть ограничения на размер одного объекта?
                                                                                        0
                                                                                        конечно есть — на почти все API у гаешечки лимит в мегабайт, только тссс… еще же можно хранить дерево ключей на шарды, а не комментов
                                                                                          0
                                                                                          Я когда писал это коммент, бегло прошвырнулся по докам и не нашёл. Помню что какие-то лимиты были «by design», какие-то «by payment», но какие где точно не помню.
                                                                                        0
                                                                                        кто ещё не читал…

                                                                                        Joe Celko's Trees and hierarchies in SQL for smarties

                                                                                        скачать в PDF на варезниках не проблема
                                                                                          0
                                                                                          SQL и гугловский BigTable — две большие разницы. В частности выборка сущностей, находящихся в отношении композиции с основной «таблицей» операция более дешевая вроде как. Сущностей, находящихся в отношении агрегации — более дорогая. А уж выборка «внешней» сущности (контейнера) по «внутренней» — очень дорогая.
                                                                                          +2
                                                                                          В данном случае хэш содержит как бы три двузначных разряда: комментарии нулевого уровня нумеруются в двух первых разрядах, второго в двух вторых и так далее.

                                                                                          Хэши, блин.
                                                                                          Битовые (bitwise) операции (как упаковать 2 16-битных числа в одно 32-битное и т.п.) значит уже все забыли? %)
                                                                                            0
                                                                                            поддерживает ли Ваша структура данных изменения? Напр., перенос ветки обсуждения в другую «тему» (если представить, что мы имеем дело с форумом).
                                                                                              0
                                                                                              Фактически нет, то есть это надо всё перенумеровывать заново будет, ещё одно ограничение, которое в случае комментариев значения вообще не имеет, но может иногда играть роль, действительно.
                                                                                              –2
                                                                                              В нашей web студии давно работает полностью иерархическая cms, и уже очень давно.
                                                                                              Плюсов очень много, на порядок проще b быстрее любой обьектной cms.
                                                                                                0
                                                                                                А можете привести пример популярной объектной CMS. Мне всё как-то больше иерархические попадаются, пускай даже не с одним уровнем иерархии. Самая близкая к объектной, имхо, Drupal, но и там «мышкой» нельзя (7-ку не смотрел) построить модель предметной области, если она не вписывается в таксономию.
                                                                                                  0
                                                                                                  Популярной иерархической open source CMS — нет, только закрытые. :\
                                                                                                  Практически все обьектные, в той или иной мере, там архитектура далека от иерархии. Какие иерархические вам попадаюся?
                                                                                                    0
                                                                                                    Хотя бы закрытой. Что-то там в ГК есть личные и исследовательские цели ;)

                                                                                                    То есть все позволяют в той или иной степени создавать пользователю новые типы данных (классы объектов) и их экземпляров (объекты), создавать им новое поведение, наследовать один тип от другого и изменять поведение родителя. произвольно (а не только иерархически) связывать один объект с другим?
                                                                                                0
                                                                                                Изобретать вилосипед полезно и интересно. Но есть же Adjacency List, Materialized Path, Nested Sets (упомянутые выше). Все это замечательно работает под определенными задачами и имеет множество готовых реализаций…
                                                                                                  +1
                                                                                                  Это так, но ведь и вы же написали этот комментарий, хотя минимум уже трижды было озвучено? ;)
                                                                                                  0
                                                                                                  Благодаря этой статье нашел Вашу.
                                                                                                  Я писал про эту же тему, только делал с цифровым ключом :)

                                                                                                  Only users with full accounts can post comments. Log in, please.