Мой предыдущий пост был несколько сумбурным и оставлял множество спорных возможностей. Но поскольку этот журнал всё равно никто не читает, то в комментах это всё равно не отразилось :D
После этого, я ещё достаточно много над этим думал и вот, до чего дошёл:
- Теги - это средство группировки. Приписываение тега эквивалентно добавлению в группу. В нашем случае это будут любые объекты, которые требуется хранить в БД. Имя тега, соответственно, эквивалентно имени группы. Далее для определённости будет использоваться термин "группа".
- Любые(!) объекты БД можно объединять в группы.
- Объекты БД являются связанными друг с другом, если они находятся в одной группе. При этом обратное утверждение необязательно верное.
- Запрос к такой системе выглядит как набор имен групп, объединенный логическими операциями "И" или "ИЛИ"
- После обработки запроса на выходе выдаются:
- множество объектов, удовлетворяющих условиям запроса
- множество групп (оно включает не только группы из запроса), в которые входят найденные объекты. Это множество позволяет получить все необходимые связи найденных объектов.
Технически, указанная выше схема может быть реализована на реляционной БД. Каждый объект такой БД хранится в одной или нескольких таблицах. У него обязательно должен быть primary_key, который сможет однозначно идентифицировать этот объект. Для обработки связей объектов между собой создаётся единая таблица отношений со столбцами ID_объекта и ID_группы. Таким образом, как и отмечалось в предыдущей статье, нет необходимости создавать отдельную таблицу для каждого из отношений. С другой стороны, неизвестно, какой из методов будет работать быстрее в каждой из современных реляционных БД. С точки зрения SQL запрос из п.3 будет выглядеть достаточно сложно. При N групп, это будет либо N операций JOIN таблицы отношений с самой собой, либо N вложенных подзапросов. В связи с этим, сама идея требует дальнейших исследований и возможно, создания собственной системы хранения, которая будет более оптимальной, нежели реляционные БД.