Не могу определиться с вариантом организации связи таблиц-сущностей с тегами:
1 ) Есть несколько таблиц-сущностей предметной области, каждая из которых (сущность) имеет набор тегов
2 ) Теги хранятся в отдельной таблице и имеют свой ID

Возможны 2 варианта организации связи таблиц-сущностей (М:М) с тегами:
1 ) отдельные таблицы связей для каждого вида сущностей: (entity1_id, tag_id) , (entity2_id, tag_id) , ...
2 ) общая таблица связей: (entity_type, entity_id, tag_id)

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

Возникает вопрос, нужен ли такой общий поиск, поскольку в этом случае для сортировки и фильтрации общего списка (как минимум, фильтрация будет выполняться всегда ) всё равно придётся JOIN'ить таблицы сущностей и задавать условия по полям этих сущностей - данный фактор сводит на нет озвученное преимущество общей таблицы и почти уравнивает его с вариантом отдельных таблиц связей, когда поиск тега сразу для нескольких сущностей будет реализовываться несколькими поисками для отдельных сущностей с теми же фильтрациями и сортировками по полям сущностей.

авторВыглядит так будто анализ предметной области проведён криво и выделение сущностей не
доведено до логического конца.Факт наличия более одной сущности, имеющей теги, абсолютно ни о чём не говорит. Имхо, обычное явление.

авторСкорее всего у тебя должна быть только одна сущность, обложенная тегами и как результат -
связь всего двух таблиц M:N.
При определении того, нужно ли оформлять сущности отдельными таблицами или общей таблицей, фактор наличия тегов (равно как и фактор наличия текстового контента) не всегда играет решающую роль. В данном случае:

1 ) просто семантически сущности разные (обычно на форумах обсуждают такие сущности, как новости и статьи )
2 ) большинство (ни или половина) полей/характеристик у этих сущностей - свои индивидуальные (в общей таблице будет много "дырок" с NULL, что не есть хорошо)
3 ) чем меньше данных в таблице, тем быстрее работает выборка по индексам
4 ) чем меньше индексов в таблице - тем быстрее выполняются операции вставки/удаления/обновления

Здесь может стоять вопрос вынесения общих семантически равнозначных полей в отдельную таблицу (в данном случае - текстовый контент), и уже с этой таблицей связывать теги. И снова несколько но:

1 ) дублирование поля контента в каждой сабжевой таблице-сущности позволит избежать лишнего JOIN при выборке без создания избыточности (дублирования) данных
2 ) теги могут иметь и сущности без текстового контента (если и не сейчас, то в будущем)
3 ) не все сущности с текстовым контентом имеют теги

P.S . Таким образом, сабжевый вопрос остаётся в силе...

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

Dimitry Sibiryakov Хоть Вы так и говорите, но, похоже, для себя уже всё решили.
По поводу организации сабжевых сущностей в отдельных таблицах - да, решил (и привёл аргументы)
Но по вопросу организации их связей с тегами - нет.

Dimitry Sibiryakov Кривая архитектура БД вылезет позже в виде геморроя с запросами тормозов. Тогда и переделаете.
Я предпочитаю оперировать конструктивными доводами, а не ярлыками. На текущий момент вы не озвучили ни вашего варианта организации сущностей с контентом и тегами (общая таблица с "дырками", отдельные таблицы, как у меня сейчас, или иной вариант), ни каких-либо доводов против варианта с отдельными таблицами-сущностями .

Почему вы считаете, что вариант с отдельными таблицами-сущностями приведёт к "геморрою с запросами" и тормозам ? Отсутствие дополнительного JOIN - это разве приведёт к тормозам и сделает запрос сложнее ? Отсутствие "дырок" и малое количество индексов в одной таблице - это разве усложнит запросы и приведёт к тормозам ?

Со своей стороны я привёл доводы в 3-м посте. Если вы приведёте везкие контраргументы , я могу и переделать архитектуру . Но на текущий момент таких доводов нет, а значит, нет объективных причин считать текущую архитектуру "кривой".

"Опыт - сын ошибок трудных." (с)
Значит, аргументов не будет ?

Отсутствие дополнительного JOIN - это разве приведёт к тормозам и сделает запрос сложнее ?
Отсутствие "дырок" и малое количество индексов в одной таблице - это разве усложнит запросы и приведёт к тормозам ?

stenfordзвучит как классическая задача с наследованием, там 3 подхода - все в одну таблицу, по таблице на каждый подтип и общие характеристики вынесены в таблицу супертипа, по таблице на каждый подтип со всеми характеристиками. Что использовать зависит от конкретного случая, сколько общих аттрибутов, сколько разных, какие операции над ними преобладают итп. Именно. И каждый из вариантов имеет место в проектах:
автор таблица на тип (TPT)
каждый класс имеет свою собственную таблицу. Базовый класс имеет все элементы базового класса в нем, и каждый класс, производный от него, имеет свою собственную таблицу с первичным ключом, который также является внешним ключом к таблице базового класса; класс производной таблицы содержит только различные элементы.
таблица на иерархию (TPH)
существует одна таблица, которая представляет всю иерархию наследования, что означает, что несколько столбцов, вероятно, будут разреженными. Добавляется столбец дискриминатора, который сообщает системе, какой тип строки это.
таблица-на-класс (TPC)
каждый класс имеет свою собственную полностью сформированную таблицу без ссылок на любые другие таблицы.Вариант, предлагаемый Dimitry Sibiryakov , - это либо TPT , либо TPH (какого именно варианта он придерживается, пока неизвестно, но мы терпеливые).
По скорости выборки лидируют варианты TPH и TPC , по скорости добавления/удаления/обновления - TPC (меньше индексов). По минимальному объёму занимаемого дискового пространства лидирует TPC , за ним следует TPT. Как мы видим, по всем 3 озвученным критериям лидирует вариант TPC , на котором мы и остановились.

Правда, нужно сделать оговорку: нет связей с другими классами-таблицами, участвующих (связей) в организации иерархии. При этом, естественно, есть: связи с таблицами связей М:М, связи с таблицами-неклассами, связи с таблицами-классами, не участвующие (связи) в организации иерархии.

vmagили как уйти от EAV... EAV - это существенное упрощение архитектуры БД за счёт существенного усложнения контроля ссылочной целостности и существенного снижения производительности запросов. Если состав полей постоянен или относительно постоянен, то EAV не нужен. В сабжевом случае EAV и не пахнет.

graycodeДля начала нужно ответить на вопрос зачем нужны теги, как и для чего они используются, какого вида запросы по ним будут.Запросы будут классические:
1 ) " найти все сущности указанного типа, имеющие 1 или несколько указанных тегов "
2 ) " получить список всех тегов указанной сущности "

Запросы вида " найти все сущности нескольких типов, имеющие 1 или несколько указанных тегов" не в приоритете, поскольку в таком списке (по крайней мере, на первых страницах пагинации) может оказаться только одна сущность, тогда как пользователь, пожелавший выполнить поиск по тегам сразу для нескольких сущностей, скорее все захочет уже на 1-й странице пагинации увидеть все виды сущностей. А для реализации такого результата по-любому придётся выполнять отдельные теговые поиски по каждому виду сущностей.

graycodeИ далеко не факт, что использование классических таблиц и индексов лучший подход для запросов по тегам.Что в имеете ввиду под " неклассическим " подходом ?

zeon11 Не знаю, поможет, или нет. Сделал для мелочевки ОДНУ таблицу с иерархией.Насколько я понимаю, это у вас справочники. Только не понял, для чего нужна иерархия - ведь справочники-то независимые, судя по скрину. Да, их можно хранить в отдельной таблице. Но можно и в разных. Если их не огромное количество и они не формируются пользователем, то смысла объединять в одну таблицу нет, т.к. общая таблица справочников усложняет поддержание ссылочной целостности и в целом обслуживание...

авторЯ за одну таблицу. Гораздо проще будет управлять. И кода писать в разы меньше. За одну общую таблицу сущностей или за одну таблицу связей (entity_type, entity_id, tag_id) ?
В нашем случае приоритет имеет скорость операций, нежели чем простота проектирования. Что касается объёма кода, то всегда можно воспользоваться готовой или реализовать собственную ORM или Query Builder , которые скроют логику работы с таблицами.

Ennor TiegaelЯ обычно выбираю второй вариант. Когда этих тэговых связок будет в районе хотя бы 50-ти, и вы решите добавить в них новое поле, вы пожалеете о сделанном выборе.Ручного добавления/удаления/изменения поля легко можно избежать:
1 ) хранимые процедуры или функции, которые делают это автоматически, используя information_schema
2 ) механизм наследования (например, в PostgreSQL): добавляем/изменяем/удаляем поле в базовой таблице - и оно автоматически добавляется/изменяется/удаляется во всех дочерних таблицах

Ennor TiegaelВпрочем, если простота администрирования у вас на предпоследнем месте, сразу перед проектированием, то вперед, конечно. Т.е. вы считаете, что вариант с отдельными таблицами будет работать эффективнее ?

graycodeНе не не, не в приоритете из за сложности имплементации, это очень слабая аргументацияЧто сложность реализации не должна иметь решающего значения - согласен на 100%. Но под словами " не в приоритете " я имел ввиду не сложность реализации, а невостребованность данной функциональной возможности (отображение общего списка сущностей, связанных с указанным тегом). Вместо этого должны будут реализовываться отдельные списки для каждого раздела/типа сущностей (как в тех же социальных сетях).

graycodeпоскольку сложности нет никакой и вывести на страницу разделы в которых показать по одной сущности плюс ... по искомым тегам тоже проблем нет, посмотрите поиск по соцсетям, там совершенно спокойно по искомому слову выдаются в качестве результата перечень разделов люди/сообщества/фильмы/музыка/обсуждения и т.п.Вопрос в том, как будут генерироваться такие отдельные списки. Если отдельными поисковыми запросами для каждого списка (типа сущностей, раздела), то общая таблица связей в этом плане не будет иметь преимуществ над отдельными таблицами связей . Но если такие отдельные списки будут формироваться одним запросом (что более эффективно) - такой вариант реализуем только с общей таблицей связей , включающей все типы сущностей (разделы).

Вопрос №1 . В социальных сетях поиск осуществляется одним запросом по всем разделам или несколькими запросами (по запросу на каждый раздел) ?
Вопрос №2 . В социальных сетях поиск осуществляется только по контенту или в том числе по индивидуальным полям сущностей (название, комментарий, имя вложения/альбома и т.д.) ?

graycode1. Создавать таблицу для тегов как самостоятельной сущности нет никакой необходимости.
2. Создать таблицу можно, но не делать на нее ссылок, просто использовать как перечень тегов существующих в системе.Имеете ввиду справочник доступных (допустимых) тегов ?
В нашем случае теги будут постоянно добавляться пользователями, т.е. перечень допустимых тегов ограничиваться не будет.

Плюс, в обоих случаях мы столкнёмся с "избыточностью" данных, поскольку многие-многие экземпляры сущностей будут иметь одинаковые строковые теги - а это сильно увеличивает потребление дискового пространства. Гораздо экономнее ставить числовые идентификаторы на таблицу тегов.

graycode3. Создать такую же таблицу как во втором пункте, но добавить к ней таблицу с типами сущностей для тегов. 1 ) справочник со списком всех допустимых тегов (tag_id, tag)
2 ) справочник допустимых тегов для каждого типа сущностей (entity_type, tag_id)
Такую схему вы имеете ввиду ?

graycodeУчитывая суть тегов, я бы остановился на первом варианте, т.е. (entity_type, entity_id, tag), поисковые запросы по тегам или тег плюс тип сущности. Т.е. ваш вариант: общая таблица связей для всех типов сущностей, но вместо идентификатора тега указывается строка тега .
Преимущество этого варианта - отсутствие JOIN для связи с таблицей тегов. Недостаток - большое потребление дискового пространства.

Cyrax_02Но если такие отдельные списки будут формироваться одним запросом (что более эффективно) - такой вариант реализуем только с общей таблицей связей, включающей все типы сущностей (разделы).
Вопрос №3 . Как из общей таблицы (entity_type, entity_id, tag) одним запросом (без UNION) получить N сущностей типа 1 , N сущностей типа 2 и N сущностей типа 3 , связанных с указанным тегом ? В социальных сетях получают ))

graycodeПоиск осуществляется в документах и индексы строятся полнотекстовые по документам.По индивидуальным строковым полям сущностей тоже строятся. Например, название новости/статьи, abstract новости/статьи и т.д. И эти поля, как правило, имеют большую релевантность.
А в PostgreSQL один полнотекстовый индекс можно строить сразу по нескольким текстовым полям сущности (и даже из разных таблиц).

graycodeОткуда потребление дискового пространства?
Тег по своей природе это короткий строковый неструктурированный классификатор, я бы даже сказал индексатор, выносить его в отдельную сущность не имеет никакого смысла. 1 ) В случае с отдельной таблицей тегов в таблице связей (entity_type, entity_id, tag_id ) мы храним идентификатор тега (целое число)
2 ) В случае без таблицы тегов в таблице связей (entity_type, entity_id, tag ) мы храним строку
3 ) Строка занимает намного больше места, чем число

graycodeЗачем одним запросом? Пройтись в цикле по сущностям никак?Можно и в цикле. Но одним запросом (без UNION) будет быстрее. К тому же, вы сказали, что это возможно:

> Вопрос №1. В социальных сетях поиск осуществляется одним запросом по всем разделам или несколькими запросами (по запросу на каждый раздел) ?
> Какая разница, и то и другое реализуется

Вопрос : " одним запросом по всем разделам " реализуется как ?

graycodeИли у вас все таки одна сущность на самом деле?
Для разных вам все равно создавать на выдачу в веб разные модели или у вас одна модель и один компонент для всех сущностей? Сущностей-таблиц много. Модели разные. Компонент один.
В том-то и дело, что разные модели - это только на выдачу. А выборку эффективнее (быстрее) делать одним запросом

graycodeCyrax_02 1 ) В случае с отдельной таблицей тегов в таблице связей (entity_type, entity_id, tag_id) мы храним идентификатор тега (целое число)
2 ) В случае без таблицы тегов в таблице связей (entity_type, entity_id, tag) мы храним строку
3 ) Строка занимает намного больше места, чем числоВо первых, короткая строка не занимает намного больше места, возьмем к примеру тег #sqlru и сравним с number(38), во вторых, вы имеете в нагрузку PK, индекс на PK, FK и индекс на FK и это помимо индекса на тег и экономия места становится совсем сомнительной.
1 ) Не знаю, как в Oracle, но в MySQL и PostgreSQL целочисленный тип с фиксированной точностью занимает 2,4 или 8 байт.
Для хранения тегов достаточно 2 или 4 байтов (в зависимости от предполагаемого количества уникальных тегов).
2 ) Для хранения тега " sqlru " в строковом формате переменной длины потребуется 4 байта + байтовая длина строки = 9 байт
3 ) Для хранения русскоязычных тегов в кодировке UTF-8 (коих будет в десятки раз больше, возьмём, к примеру, тег " домру " той же самой длины), потребуется: 4 + 10 = 14 байт
4 ) Русскоязычные теги (как и русские слова) в среднем в 1.5 раза длиньше латинских: 14 * 1.5 = 21 байт .

Выводы :
1 ) для преобладающего большинства коротких тегов потребуется в 5-10 раз больше дисковой памяти
2 ) для преобладающего большинства средних и длинных тегов потребуется в 10-30 раз больше дисковой памяти.

Что касается PK, FK и индексов :
1 ) Индекс на FK в таблице связей (т.е. индекс на поле tag_id или tag ) будет присутствовать в любом случае, т.к. по этому полю выполняется поиск (выборка)
2 ) Индекс по строковому полю tag будет занимать гораздо больше места на диске, чем индекс по числовому полю tag_id
3 ) в случае со строковым полем tag дополнительный составной индекс будет включать строковое поле tag и числовое поле entity_type_id , тогда как в случае с tag_id составной индекс будет включать два числовых поля tag_id и entity_type_id (займёт меньше места)

4 ) Наличие двух дополнительных числовых индексов в случае с отдельной таблицей индексов будет давать выигрыш (если вообще будет давать с учётом пункта №3) только до тех пор, пока общее число экземпляров тегов по всем сущностям будет соразмерно общему числу уникальных тегов в таблице тегов . Иными словами, в таблицу тегов добавляются только новые (уникальные) теги, а в таблицу связей - и новые, и повторяющиеся. Когда повторяющихся тегов станет чуть больше, чем число тегов в таблице тегов, то это самое преимущество по индексам (повторюсь, если оно вообще будет) обнулится ( на практике число тегов с повторами в сотни и тысячи раз превышает число уникальных тегов ). И начиная с этого момента будет играть роль исключительно вышерассмотренный фактор объёма памяти, требуемого под хранение строк и чисел ( разница в 5-30 раз ).

graycodeТем более если у вас имеет место pagination, нужно будет делать выборку для определения общего количества элементов для каждого типа сущности, т.е. количество с группировкой по entity_type.Пагинация да, будет. Но запрос на пагинацию почти идентичен запросу на выборку. Вопрос в том, каким будет этот самый запрос на выборку.

graycodeЧто мешает сделать один заброс с left join-ами, если уж решили для каждой сущности иметь свою таблицу, когда будете собирать их вместе, будете иметь дело с left join-ами или union-ами...
Не факт и не всегда и ничего не мешает сделать выборку из (entity_type, entity_id, tag) одним запросом или вам что то мешает?Вопрос касается не организации таблиц-сущностей (здесь да, вопрос решён, отдельные таблицы), а организации связи этих таблиц-сущностей с тегами - вот здесь вопрос не решён. Мы рассматриваем ваш вариант с общей таблицей (entity_type, entity_id, tag) и задаёмся вопросом: как из этой таблицы тегов одним запросом (без UNION) получить N сущностей типа 1 , N сущностей типа 2 и N сущностей типа 3 , связанных с указанным тегом ? Выше вы написали, что это возможно. Как ?

stenfordTPC имеет смысл когда общих аттрибутов мало и запросы в основном идут по всем аттрибутам. Какая именно ситуация тут знаешь только ты.Наш случай.
Важно учитывать, что поиск должен выполняться по индексу, а значит, все или почти все поисковые поля должны быть в одной таблице ( TPC или TPH ).

stenfordНа практике-же для "скорости" это не будет иметь никакой разницы если только ты не пишешь второй фейсбук. Джойн на базовую таблицу не окажет никакого практического влияния на скорость, как и индексы.Если выборка выполняется по полям, половина из которых расположена в базовой таблице, а половина - в дочерней ( TPT ), то скорость такого запроса сильно просядет, даже при наличии индексов в обоих таблицах.

stenford...нелогично сделаная схема с прицелом "на скорость" в ущерб логичности доменной модели никогда не приводит ни к чему хорошему, включая и собственно "скорость" Отдельные таблицы связей с тегами для каждого вида сущностей (entity1_id, tag_id) , (entity2_id, tag_id) сюда тоже относятся ?

авторДля хранения тегов достаточно первичного ключа в два байта длиной, нормальное такое утверждение))))), вернемся в реальность, в реальности 8 байт и 20 - 40 байт, разница даже не на порядок, это экономия на спичках, какой у вас планируется объем и его прирост?8 байт точно не нужно. Количество уникальных тегов вряд ли превысит 4 миллиарда штук. Даже если взять 4 байта (а не 2), то разница между 4 байтами и 20-40 байтами составляет почти порядок (двусловных русских тегов будет больше, чем однословных).

авторНа самом деле, если как вы написали, разные типы сущностей в конечном итоге пользователю впихиваются в один компонент, то разделение сущностей на разные таблицы и модели вызывает очень большое сомнение.Вы предлагаете строить один индекс сразу на 2 таблицы ( TPT ) ?
Или строить одну широкую-широкую таблицу с кучей "дырок" и большим числом индексов в ней ( TPH ) ?

авторN записей по каждому типу тоже просто, сейчас любая нормальная СУБД имеет механизмы получения TOP N записей в пределах группВ этом случае запрос на выборку сущностей типов 1,2,3, связанных с некоторым тегом, будет таким:

Нехороший запрос...

Альтернативный вариант:

А я же предупреждал...Вообще-то, это ваш вариант (общая таблица связей с тегами).

авторPS: вариант все сущности в одной таблице вам предложили сразу, вариант выделить общую часть сущностей, а частности в доп таблицах тоже уже предлагали, в догонку еще вариант помещения тегов в виде текста (например массив json) в поле сущности и кстати в вашей ситуации возможно самый правильный вариант)), итого количество различных вариантов и их комбинаций уже превышает десяток, выбирайте любой в зависимости от функционала и расчетной нагрузки. Все сущности в одной таблице - не вариант, т.к. сущностей много + индивидуальных полей много + фильтрация будет выполняться преимущественно по индивидуальным полям.
Общая таблица + таблицы с частностями - возникает проблема фильтрации одновременно по общим полям и по индивидуальным полям.

JSON-массив тегов в таблицах сущностей - возможно, только вместо самих тегов лучше хранить идентификаторы (JSON-массив идентификаторов тегов) + в бинарной форме (jsonb в PostgreSQL), т.к. в среднем числовое представление идентификаторов будет короче, чем символьное.

Dimitry SibiryakovВы бы определились: идёт у вас фильтрация по "индивидуальным полям" или по тэгам... При поиске сущностей по тегам всегда будет выполняться:
1 ) фильтрация по индивидуальным полям (об этом написал жирным шрифтом в самом первом посте)
2 ) упорядочивание, как минимум, по дате (для реализации TOP N, а также при пагинации)
3 ) Фильтрация по самим тегам - само собой разумеется

Все поля (индивидуальные + общие) расположены в сущностях-таблицах entity1 , entity2 , ...
Т.е. либо UNION N штук, либо GROUP + JOIN N штук. Выше привёл 2 запроса, реализующие эти два варианта.

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

graycodeкогда вы заходите с value (теги) и хотите скрестить их с условиями на сущность, будут нехорошие запросы.Если все сущности силой запихнуть в одну таблицу, что это даст ?
От необходимости одновременной фильтрации и по индивидуальным полям, и по тегам, этим самым не уйдёшь...

Dimitry SibiryakovПравильнее - спросить себя "а чем они технически отличаются от тэгов?"
Они будут хорошими если: 1) Довести идею до логического конца... Вместо тегов могут оказаться любые другие таблицы-сущности и таблицы-несущности, с которыми текущая сущность должна иметь связи 1:М
Что ж теперь, все связи из отдельных таблиц преобразовывать в собственные поля сущности ? База данных из 1 таблицы ?

Dimitry SibiryakovТы как-то проскочил логическое завершение и сразу пошёл до самого абсурда...Я говорю о том, что организовывать теги нужно в том же самом порядке, в каком выполняется организация связей 1:М в РСУБД. Можно выносить список тегов в отдельную таблицу, можно не выносить - не важно. Факт необходимости одновременной фильтрации по двум связанным таблицам не говорит о том, что БД спроектирована некорректно. И объединение сущностей в общую таблицу не избавляет от такой необходимости.

stenfordЕсли утверждается, что сущности симантически не связаны друг с другом, то должно быть по отдельной таблице для связки с тэгами один ко многим для каждой из сущностей, мешать список тэгов для несвязанных между собой сущностей в одной таблице нельзя
Если утверждается что сущности все-же симантически связаны и список тэгов это их общая характеристика, то рассматривается один из 3х вариантов с наследованием. Соответственно в случае ТРС у тебя будет по таблице с тэгами на каждую таблицу с сущностями, а в случае ТРН одна таблица с тэгами на общую таблицу со всеми сущностями
+100 . Вы, собственно, и озвучили мои мысли/выводы. А реализовал я первый вариант. Для случая отдельных таблиц-сущностей это самый чистый, самый легковесный (минимум дисковой памяти), самый быстрый (скорость выборки) и самый правильный (с точки зрения классической реляционной модели). Ну а дальше на рабочих нагрузках при необходимости можно выполнять поэтапную денормализацию для ускорения виборки/фильтрации.

P.S . Dimitry Sibiryakov почему-то принципиально отказывается рассматривать вариант отдельных таблиц-сущностей (даже на личности перейти успел). Ведь очевидно, что наличие тегов в предметной области вовсе не является определяющим фактором способа реализации иерархии ( TPH или TPC ). И тем более необходимости перехода на модель EAV .

17-77сам лично такую штуку не делал, но покопал бы еще следующий вариант: текстовое поле + where like + оптимизации для like запросов, например pg_trgm у постгреса...
на UI достаточно tag editor, который через запятую складывает значенияЕсли рассматривать вариант хранения тегов сущности в одном поле (в таблице сущностей), то здесь возможны 2 варианта:
1 ) ваш вариант с тегами через запятую (LIKE + индекс по триграммам)
2 ) вариант с массивом json (этот вариант также упоминал graycode )

В варианте с json , судя по всему, индекс по jsonb будет кушать меньше дисковой памяти. Да и поиск, наверняка, будет работать быстрее, чем по триграммам.