SQL-схема с ограничениями внешнего ключа для арендаторов

Question

Я разрабатываю базу данных для использования в сценарии с несколькими арендаторами. Я недавно узнал, что для обеспечения того, чтобы tenant_ids были согласованы между таблицами, которые ссылаются друг на друга, мне нужно, чтобы первичный ключ таблиц включал как идентификатор таблицы, так и tenant_id. Затем внешние ключи должны ссылаться как на идентификатор таблицы, так и на tenant_id.

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

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

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

(Это просто пример, а не фактической базы данных)

Answer 1

У вас есть два основных варианта здесь.

Первый заключается в добавлении дополнительных внешних ключей и уникальных ограничений, которые включают tenant_id, и если вы сделаете это, вы можете убедиться, что один и тот же арендатор ссылается по всей доске. Сделайте это, если вы хотите использовать политики безопасности на уровне строк, потому что это решит проблему с производительностью при проверке безопасности.

В этом случае плейлист будет иметь второй уникальный индекс на (id, tenant_id), а playlist_item будет иметь внешний ключ на (playlist_id, tenant_id), ссылаясь на это.

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