Дерево каталог на python?

Question

[Александр Рублев]

Всем привет. Буду писать маленькую программу каталога товаров (для себя).
Все будет храниться в mysql. Ищу какое нибудь готовое решение для дерева (каталога) товаров.
Никак не могу найти. Нашел одно шикарное для меня решение treelib, но я так понял оно не может сохранять данные и потом брать их оттуда.
Подскажите есть ли готовое решение для меня?

Comments

[qlkvg]

самый дубовый вариант - сериализовать pickle'ом и писать как blob

Answer 1

[Руслан Гильфанов]

В любом проекте на Python для работы с реляционными СУБД можно использовать ORM SQLAlchemy.

Документация по SQLAlchemy:
docs.sqlalchemy.org/en/latest

Среди дополнительных пакетов SQLAlchemy сходу нагуглил SQLAlchemy-ORM-tree для организации иерархических структур данных в реляционных СУБД. Пакет реализует паттерн Nested Set.

Документация по SQLAlchemy-ORM-tree:
https://sqlalchemy-orm-tree.readthedocs.io/

Установка пакетов через pip (или для Python3 в Linux -- pip3):

pip install SQLAlchemy
pip install sqlalchemy-orm-tree

Ещё чуть поискал, нашёл пакет sqlamp, реализующий другой паттерн хранения иерархических структур данных -- Materialized Path -- для SQLAlchemy.

Документация по sqlamp:
sqlamp.readthedocs.io/en/latest

Но я бы предпочёл SQLAlchemy-ORM-tree, паттерн Nested Set вроде имеет больше преимуществ и меньше недостатков.

Comments

[Александр Рублев]

Никогда не пользовался ORM. Писал все запросики вручную)

[Руслан Гильфанов]

Александр Рублев, если хочется писать SQL вручную, можно и так. Но, на собственную реализацию уйдёт не меньше времени, чем на освоение пакетов SQLAlchemy и sqlalchemy-orm-tree.

Популярных паттернов хранения деревьев всего четыре:

• Adjacency List
  
• Materialized Path
  
• Nested Set
  
• Closure Table
  

Если программу пишешь для себя и большой нагрузки не ожидается, можешь взять на вооружение Adjacency List.

Суть Adjacency List проста и в случае с категориями каталога:

• каждая категория в таблице может иметь внешний ключ (foreign key) на родительскую категорию в этой же таблице (т.е. рекурсивный внешний ключ),
  
• если внешнего ключа нет -- значит это категория верхнего уровня,
  
• получение отдельных веток, всех предков или всех потомков реализуется через множество запросов к СУБД в цикле (это главный минус подхода).
  

Загуглите "рекурсивный внешний ключ в MySQL" ("recursive foreign key in MySQL") и "паттерн Adjacency List в MySQL".


На практике, когда производительность важна, используют гибридные решения, вроде Nested Set + Adjacency List. А так же различные оптимизации, вроде столбца depth (глубина вложенности) в таблице связей.

По англоязычным названиям паттернов, а так же ключевым фразам вроде "иерархические структуры данных", "деревья", "реляционных СУБД" можно найти как статьи на Хабре, так и видео на YouTube. Найдутся и примеры реализации с SQL-запросами, и графические схемы для простоты понимания, и сравнение по преимуществам/недостаткам разных подходов.

Например, что можно найти за 5 минут:

• Денис Иванов -- Способы хранения иерархических структур данных (видео)
  https://youtu.be/dlFradCdjQ4
  
• Михаил Стадник -- Иерархические структуры данных и Doctrine
  https://habrahabr.ru/post/46659/
  
• Михаил Стадник -- Иерархические структуры данных и производительность
  https://habrahabr.ru/post/47280/
  
• Ян Иванов -- Хранение деревьев в базе данных. Часть первая, теоретическая
  https://habrahabr.ru/post/193166/
  
• Igor Drandin -- Хранение иерархических структур. Симбиоз «Closure Table» и «Adjacency List»
  https://habrahabr.ru/post/263629/
  

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

[Александр Рублев]

Топовый ответ! Спасибо!