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

Question

[fijj]

Возник вопрос реализации товарного дерева категорий. Всегда обычно использовал nested sets (вложенное множество ) или adjacency list (Список смежности). Если вдруг нужно поковырять базу руками такие структуры уже не очень удобны. Но в mysql есть же json поля, что если построить нужное дерево в видео json, но не понимаю как контролировать уникальность идентификатора категории в этом случае. Можно конечно для идентификатора использовать некий хеш. Но не будет ли тяжелой продуктовая таблица например на 500к позиций где category_id будет хеш. Или возможно есть какие то другие способы реализации?

Comments

[Дмитрий]

Не надо в json. Гляньте в сторону clousure tree - триггер на инсерт и апдейт, и можно руками ковыряться

[mayton2019]

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

А что большой JSON удобен? Или как автор хочет его ковырять? И вообще зачем его ковырять. В продуктовой системе должен быть UI для работы с классификатором. А если есть UI - тогда безразлично что там внизу JSON или adjacency list.

[fijj]

mayton2019, Ну с ковырянием руками может быть я и погорячился. Понятно что дальше будет UI для работы с деревом. Но тут и возникает проблема. UI будет на vue, мне нужен будет функционал сортировки потомков через drag&drop и получается в случае clousure tree и adjacency list мне нужно будет сделать запрос для получения json, после сортировки в UI полученный json уже нужно будет вновь распарсить что бы записать в таблицу. Так почему бы сразу не хранить все в json? Просто не понимаю в чем минус такой реализации. Успешно же например отказываются от EAV в пользу JSONB, так почему бы и дерево категорий не засунуть в json?

[mayton2019]

fijj, JSONB используют в тех системах где есть документооборот. И где каждый JSON/JSONb - это отдельный документ.

Можете-ли вы в вашей задаче рассматривать классификатор категорий как отдельный документ? Я не уверен. Здесь есть какая-то натяжка.

[Дмитрий]

fijj, ну если из мускула вам не нужны ни отношения, ни целостность - нахрена вам вообще MySQL? Кладете данные в json файл и вперед. Ну можете написать что нибудь что будет держать это в памяти. В чем проблемы то?

[mayton2019]

При работе с реляционной БД скоуп блокировки или просто транзакции распространяется на 1 строку или сет строк. Тоесть 2 бизнес-пользователя независимо друг от друга могут работать с классификатором и коммитить изменения. И при этом их действия с точки зрения бизнес-информации будут консистентны. Нарушить ничего нельзя если правильно спроектированы связи ограничения и правильно используются транзакции.

С документной БД есть риск получить либо заблокированный документ с которым кто-то долго работает. Либо есть риск получить ошибку класса "потерянное обновление" (очень коварная и злая ошибка) при атомарной работе. Или есть вариант что второй бизнес пользователь получит еще более сложную задачу - мержить свои изменнения с чужими. Что согласитесь вообще третья задача и она в рамках работы пользователя просто не решается. Вот 3 зла. И выбирайте из 3 зол то которое менее злое.

Answer 1

[Akina]

Но в mysql есть же json поля, что если построить нужное дерево в виде json

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

Кстати, ковыряние JSON руками... либо JSON не более сотни байт, либо ни разу не развлечение (если ты не мазохист, конечно).

Answer 2

[Mylistryx]

Adjacency List - для 1-2 уровневого меню.
Nested Sets (или Nested Trees) - для всего, что серьезней. Перестроение один раз, но выборка родителей и прочего гораздо удобней и без рекурсий\хранимых процедур.
Есть еще Mathearilzed Path - но там с хранением пути не очень, да и выборки так себе.
Для Yii2 есть шикарное решение: https://github.com/paulzi/yii2-auto-tree