Всем привет! Подскажите, пожалуйста, как лучше организовать БД для хранения древовидной структуры, у элементов которой может быть несколько родителей, чтобы в дальнейшем было удобно делать выборку для построения такого дерева средствами мускула. Для детализации моего вопроса приведу пример:
Есть электронная библиотека, в которой печатные издания распределены по жанрам (детективы (в свою очередь подразделяются на классические, исторические, детские и т.д.), фантастика (подразделяется на научную, боевую, детскую и т.д.), приключения и т.д.) и по виду издания (книги, брошюры, периодические издания (журналы, газеты) и т.д.). По сути, все элементы данной иерархии будут иметь одного родителя, но сами печатные издания могут принадлежать к разным разделам (например одна и та же книга может относиться к нескольким жанрам - детектив и фантастика). Конечная цель - возможность построить дерево с выборкой и подсчетом количества всех детей по веткам, т.е. получить дерево вида:

Книги (110)
----Детективы (35)
--------Классические (10)
--------Исторические (20)
--------Детские (5)
-------- ...
----Фантастика (40)
--------Научная (15)
--------Боевая (15)
--------Детская (10)
-------- ...
----Приключения (30)
---- ...
Периодические издания (40)
----Детективы (15)
--------Классические (5)
--------Исторические (5)
--------Детские (5)
-------- ...
----Фантастика (15)
--------Научная (5)
--------Боевая (5)
--------Детская (5)
-------- ...
----Приключения (10)
---- ...
...
.
При этом, у некоторых печатных изданий родителями могут быть не только подразделы рубрик, но и корневые разделы (в вышеприведенном дереве сумма изданий по подразделам 105 + 5 изданий принадлежат разделу Книги, итого 110.

По сути, получаются 2 таблицы: category и book. По первой таблице вопросов не возникает. А как удобнее будет хранить родителей во второй таблице book, чтобы минимизировать время выборки? Желательно, чтобы каждое печатное издание хранилось одной записью, без дублирования для каждой категории.
Заранее благодарен за Ваше потраченное время и хотелось бы выслушать разные подходы с их плюсами и минусами.

Akina,
Да, спасибо за ответ. Просто в своей практике часто встречал такой вариант организации связи таблиц:

category
id name id_parent 0Книгиnull1Детективы02Классические13Исторические14Детские15Фантастика06Научная57Боевая58Детская5

book
id name id_cat 0Воплощение воли1;71Затерянная звезда 4;82Тайны старых могил2

или даже такой, когда изначально ограничено количество родителей:
book
id name id_cat1 id_cat2 0Воплощение воли171Затерянная звезда 482Тайны старых могил2null

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

Akina,

Понял, забыл)) Спасибо.

ScareCrow,

Да, читал о вложенных множествах. Но там достаточно сложный механизм перемещения узлов, не хочется геморроя, тем более, что потом админить БД будет кто-то другой. Спасибо за направление мысли.

ScareCrowавторНо там достаточно сложный механизм перемещения узлов
один запрос?
Ну, насколько я понял, не один, а два, в зависимости от того смещаем мы узел вниз или вверх по дереву. Но вопрос в самой логике данного запроса, т.е. человеку, который будет админить БД, нужно понимать принцип построения вложенных множеств, какие области затрагиваются при добавлении, удалении, перемещении узлов вверх и вниз, учитывать порядок изменения ключей. Мне показалось немного сложновато. Может, конечно, на практике все не так страшно, но в теории выглядит более запутанно, чем таблица связей. Хотя по функционалу, конечно, достаточно удобно.

ScareCrow,

Опять же, для моей задачи вложенными множествами можно организовать таблицу category, а для связи с таблицей book все равно нужна таблица связей, т.к. NESTED SETS подразумевает наличие только одного родителя.