Что лучше использовать для древовидной структуры данных?

Question

[Даниил Колесниченко]

Нужно сделать базу данных с категориями и товарами, причём категории могут быть вложены друг в друга и товары могут быть в одной категории с другими категориями. Подходят ли для этой задачи реляционные БД? Или лучше взять что-нибудь типа Mongo (мне вот кажется, что в BSON'е описать то что мне нужно гораздо проще)?

Comments

[Сергей]

Выбор сильно зависит от операций (выборка, фильтрация, вставка, удаление), которые вы будете выполнять с данными.

[Даниил Колесниченко]

Сергей: будет древовидная таблица с товарами и категориями товаров, и ещё одна таблица, в которой будут цены на эти товары у разных производителей.
То есть, например, в первой таблице есть товар с ID=5, каким-то именем, описанием и т. д.
Во второй таблице есть запись с ID=0, ID_производителя=42, ID_товара=5, цена=$5
И есть ещё одна запись с ID=1, ID_производителя=666, ID_товара=5, цена=$4.5
Ну и ещё таблица производителей.
На стороне клиента должна быть возможность просмотреть всё дерево товаров и категорий, выбрать какой-то товар и посмотреть список цен на этот вид товара от разных производителей.
Вроде понятно объяснил более-менее :)

[Сергей]

NoSQL проблематична поддержка целостности и каталог должен быть разумного размера.
SQL имеет 3 варианта:
фишки типа nested sets - привязка к конкретной СУБД, но решает большинство проблем
хранить родитель-дети (PK-FK) - удобно добавлять, удалять, перемещать узлы и поддерево, удобно выбирать прямых потомков узла, но при выборе и/или фильтрации ветви неизвестная глубина доставляет проблемы.
хранить level + order - быстрые, удобные выборки/фильтрация без объединений но определённые проблемы с добавлением, удалением и перемещением.

Answer 1

[matperez]

Реляционная база подходит. Можно использовать nested sets или materialized path. Почитайте про оба решения. Для того и другого скорее всего есть готовые реализации в используемом вами языке.
В Mongo действительно проще описывать древовидные структуры, но сложнее их поддерживать в актуальном состоянии.
Я бы взял то, что более знакомо и для чего легче лично вам найти хороших специалистов.

Answer 2

[d'Ivan]

Лучше избегать сильную вложенность категорий. При работе с реляционными БД придётся составлять сложные запросы с join.
Если есть много связей между сущностями, то порой стоит опробовать решение с графовыми БД.
В каких случаях подходит графовая БД
Ну а в целом, Mongo наверно не подходит для задачи.
Виды NoSQL