Ладно, озвучу задачу полностью (я и не отрицаю, что могу

выражаться непонятно).
К сообщению можно прикреплять 2 вида файлов и два вида гиперссылок. Гиперссылки идут через разметку сообщения, их по сути я просто вручную обратно индексирую (в отдельные таблицы). Но два вида файлов - медиа (фотографии и картинки) и аудио - как записывать в таблицу? Каждый загруженный файл имеет уникальный id (BIGINT). И если аудио-файлы просто идут списком (отдельные строки в таблице прикреплённых аудио с позицией), то как хранить медиа? Они же у пользователя представляются в двухмерном виде. К примеру (как это у меня без БД есть):
[
[1, 2],
[1, 3]
]
Говорит, что слева картинка с ID 1 на две ячейки, справа сверху 2-ая, справа снизу 3-тья. На ум приходит только что-то вроде такого:
CREATE TABLE media (
id BIGINT NOT NULL,
channel BIGINT NOT NULL,
original TIMESTAMP NOT NULL,
x SMALLINT[2] NOT NULL, -- Начало и конец по горизонтали слева направо
y SMALLINT[2] NOT NULL, -- Начало и конец по вертикали сверху вниз
enabled BOOLEAN NOT NULL DEFAULT TRUE,
PRIMARY KEY (channel, original, x, y),
FOREIGN KEY (id) REFERENCES files (id),
FOREIGN KEY (channel, original) REFERENCES messages (channel, posted)
)

Ну если можете перекрыть то да х, у и level, а что?))))

то как что-то отображается никак не должно влиять на то как что-то хранится в базе. Интерфейс может быть разным

Знаю, поэтому и спрашиваю как лучше в базе такое проворачивать

level что бы точно гарантировать что выше, что ниже?

Запретить делать указание на позицию картинки ) Попробуйте в телеге )))))

Так в телеге как-раз недавно завезли ручную выборку позиций картинок, не?

можно хранить просто списком. отрисовать это - задача интерфейса. Важен только порядок аттачей к сообщению (на самом деле и он не особо важен)

Относительно чего))))

Вопрос не в отрисовке. Вопрос в том, как хранить как-раз, если массив двумерный, а элементы могут занимать разное количество по ширине и высоте.

Занимать где ?))))))))))

вы опять пытаетесь хранить в базе координаты для интерфейса. Не завязывайтесь на интерфейс и на внешний вид. Есть сообщение, у него есть список аттачей - все

Я тут мимо проходил с нашим ботом (кому интересно и готов тестировать, выдавая честно фидбэк -- https://slack.postgres.ai и меня пинганите), вот что он выдал: --- Понял, вы ищете способ моделирования аттачей сообщений (медиафайлов и аудиофайлов) в базе данных, не привязываясь к интерфейсу. В таком случае, для работы с аттачами сообщений можно использовать простую модель с одной таблицей для всех аттачей и как минимум одной вспомогательной таблицей для связи с сообщениями. Пример такой схемы: sql -- Таблица для файлов (аттачей) create table attachments ( id bigserial primary key, type text not null, -- 'audio', 'image', 'video' etc. file_id bigint not null, -- другие поля, связанные с файлом, например, метаданные -- Дополнительные атрибуты могут быть добавлены здесь foreign key (file_id) references files(id) ); -- Таблица связи аттачей с сообщениями create table message_attachments ( message_id bigint not null, -- ID сообщения с которым связан аттач attachment_id bigint not null, -- ID аттача из таблицы attachments position int not null, -- Позиция аттача в списке (для аудио или если порядок важен) primary key (message_id, attachment_id), foreign key (message_id) references messages(id), foreign key (attachment_id) references attachments(id) ); -- Таблица сообщений, предполагая что она у вас уже есть create table messages ( id bigserial primary key, channel_id bigint not null, -- другие поля связанные с сообщением -- Дополнительные атрибуты сообщений могут быть добавлены здесь ); В этой схеме каждый файл (медиафайл или аудиофайл) привязывается к сообщению через таблицу message_attachments, которая позволяет вам сохранять информацию о порядке аттачей в сообщении, если это необходимо. Для медиафайлов, которые не предполагают двухмерное представление, хранить координаты не требуется, и таблица attachments служит для хранения метаданных и самих файлов. Такая структура предусматривает расширяемость, если потребуется хранение дополнительных атрибутов для аттачей, и не предполагает связь данных с интерфейсом или отображением. --- В тему или не особо?:)

Явно не GPT. Я его уже третий час этим же вопросом пытаю. Сейчас изучу.

Какую версию пытаете?

Не. Эта структура только под одномерный порядок. А у картинок и видео он многомерный

Начало и конец – ужэ лучшэ, чем каждую накрытую ячейку лэйаута! Впрочем, я бы отдельно хранил список ресурсрв поста (один-ко-многим, классическое, с fkey и проверками вменяемости), и отдельно — разметку со ссылками на ресурсы поста (text или jsonb, в ссылке — тэги, уникальные для ресурса в посте, обычно безсмысленные).

Да, это уже разделено. Пока что я вот https://dbfiddle.uk/hhztsO7l. Немного безумный путь (там ещё и TEMP-TABLE будет), но мои полномочия выше уже всё.

Ну и, тогда внутри этого лэйаута поста низачем ненужны реляцыонные проверки и констрейнты – и можно его хоть в массиве, хоть в bytea хранить.

И да, некоторый минимум списка параметров табличного лэйаута, хе-хе: https://www.tcl.tk/man/tcl/TkCmd/grid.html#M9

Не особо. Рекламируйте свой бредогенератор на профильных ресурсах.