Таблица выглядит вот так. Собственно:
id - id самой записи
entity_id - id в нашей системе. То самое поле, из-за которого вопрос, каким образом его можно привязать к реальным сущностям в других таблицах, особенно в случае удаления этой сущности или удаления этой записи о сущности: триггером с какой-то процедурой перебора по тайпам, какой-то виртуальной таблицей/колонкой, хз.
entity_type - enum (пока что), что это именно: проект, таска, лог, журнал, запись, etc.
external_provider - enum (пока что), т.к. пока что поддерживаем ограниченное количество связываемых систем, обозначающий скорее общее название сервиса, т.к. мы работаем в том числе с self-hosted решениями и обслуживаем сразу нескольких. В этом случае провайдер будет один, а сурс будет отличаться
external_source - url, важно в случае self-hosted вариантов чужих систем
external_additional_data - понятно.

Таблица выглядит вот так. Собственно:
id - id самой записи
entity_id - id в нашей системе. То самое поле, из-за которого вопрос, каким образом его можно привязать к реальным сущностям в других таблицах, особенно в случае удаления этой сущности или удаления этой записи о сущности: триггером с какой-то процедурой перебора по тайпам, какой-то виртуальной таблицей/колонкой, хз.
entity_type - enum (пока что), что это именно: проект, таска, лог, журнал, запись, etc.
external_provider - enum (пока что), т.к. пока что поддерживаем ограниченное количество связываемых систем, обозначающий скорее общее название сервиса, т.к. мы работаем в том числе с self-hosted решениями и обслуживаем сразу нескольких. В этом случае провайдер будет один, а сурс будет отличаться
external_source - url, важно в случае self-hosted вариантов чужих систем
external_additional_data - понятно.

Я опять нифига не понял...

Это что, вопрос про то, как сделать внешний ключ по составному первичному ключу?

Я так понял, что про FK на несколько таблиц

Это как? Такого не бывает

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

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

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

Если таблица ссылается на две таблицы, она ссылается на одну, которая, в свою очередь, ссылается на другую.

В случае использования подхода с наследованием, FK ссылается на одну таблицу, являющуюся родителем дочерних, которые наследуются от неё

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

> а можно использовать функционал, имеющийся в постгрес - наследование таблиц, и на основе этого сделать полноценный FK.

Нет, нельзя. https://wiki.postgresql.org/wiki/Don%27t_Do_This#Don.27t_use_table_inheritance написано не просто так.

Я не увидел причин, делающих использование наследования для данной задачи невозможным.

Я не увидел причин, делающих использование наследования для данной задачи невозможным.

Ярослав же не об этом, а о том, что наследование PG вообще нигде не следует применять.

Привет, вопрос по PostgreSQL, у меня было таблица на проде в который было 180млн записей, после отчистки этой таблицы, запросы в нее выполняются очень медленно, может знаете в чем дело?