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:М в РСУБД. Можно выносить список тегов в отдельную таблицу, можно не выносить - не важно. Факт необходимости одновременной фильтрации по двум связанным таблицам не говорит о том, что БД спроектирована некорректно. И объединение сущностей в общую таблицу не избавляет от такой необходимости.