Мне интересно, есть ли у Postgres общепринятый способ обработки следующего сценария.
В моей компании есть коллекция изображений, доступных для поиска наших клиентов. У нас есть команда, которая 'помечает' изображения, чтобы помочь - тегами могут быть такие вещи, как места (Лос-Анджелес) или временные рамки (1970-е годы) или эмоции (счастливые, возбужденные и т. Д. c)
Изображение может иметь любое количество тегов. Прямо сейчас теги хранятся в виде обычного текста в формате с разделителями-запятыми в текстовом поле Postgres для строки изображения. Мы добавляем эти теги в нашу поисковую систему (в нашем случае Elasticsearch, но это не важно), и это все, что мы делаем с ними.
Мы хотим чего-то большего в нашей следующей итерации. В частности, у нас есть проблема с тегами с ошибками, и мы, как правило, хотим больше организации, чем разделенный запятыми список текста.
В идеале, у нас должна быть родительская таблица с именем tag_buckets, которая будет содержать имена категорий и идентификатор для каждого из них. - Временной интервал, эмоции, местоположение и т. Д. c, все получат запись в этой таблице.
Вопрос в том, как нам поступить с самими тегами, как структурировать их таблицу (ы)? Тэгу эмоций потребуются поля, отличные от тега местоположения, поэтому я не могу иметь одну таблицу tags с полями в ней, которая охватывает все базы.
Полагаю, я мог бы сделайте это, но это будет большая таблица с 10 текстовыми столбцами, 10 столбцами даты, 10 столбцами чисел c и, возможно, для большей логики. Большинство строк в нем будет иметь множество неиспользуемых полей. Звучит не идеально.
Но мне также не нужна отдельная таблица для каждого типа тегов - например, emotion_tag_table или location_tag_table. Это может быть очень громоздким, так как будет изобретено больше типов тегов.
Другая возможность, о которой я могу подумать, это отдельная таблица tags с, скажем, тремя столбцами - столбец с именем tag_bucket_type для хранения внешнего ключа. связь с таблицей tag_buckets, столбец внешнего ключа с идентификатором изображения, к которому относится тег, и третий столбец с именем «attribute» с объектом JSON, в котором будут храниться атрибуты тега и соответствующие значения.
У этого дизайна также есть проблемы, одна из которых заключается в том, что в СУБД нет ничего, что препятствовало бы тому, чтобы у тега были неверные атрибуты в третьем столбце. Поэтому у меня могло быть два «счастливых» тега, каждый с разными атрибутами JSON, потому что кто-то напутал, и СУБД не смогла предотвратить это.
Ни один из этих подходов не особенно привлекателен, и мне было интересно, если Postgres есть способ справиться со сценарием, в котором у вас есть похожие, но не точные типы данных, которые не могут полностью вписаться в одну таблицу. Звучит так, будто здесь не нужно решение SQL, но я не уверен, что Postgres, возможно, был способ решить эту проблему.