Я попытался создать внешний ключ в одной из моих таблиц, ссылаясь на столбец таблицы в другой схеме.
Что-то вроде этого:
ALTER TABLE my_schema.my_table ADD (
CONSTRAINT my_fk
FOREIGN KEY (my_id)
REFERENCES other_schema.other_table(other_id)
)
Поскольку у меня были необходимые гранты, это работало нормально.
Теперь я задаюсь вопросом, есть ли причины не ссылаться на таблицы в другой схеме или что-то, о чем нужно быть осторожным?
Нет проблем с этим. Схема действительно не влияет на установление внешних ключей между таблицами. Просто убедитесь, что соответствующие люди имеют разрешения, необходимые для схемы, которую вы собираетесь использовать.
Это будет работать как внешний ключ, который ссылается на таблицу в своей собственной схеме.
Как и в случае с обычными внешними ключами, не забудьте индексировать my_id, если родительский ключ когда-либо обновляется, или если вы удаляете записи из родительской таблицы (неиндексированные внешние ключи могут быть источником массивного конфликта, а индекс обычно полезно в любом случае).
Единственное, на что я столкнулся, это убедиться, что разрешение существует на другой схеме. Обычный материал - если эти разрешения исчезнут по какой-либо причине, вы услышите об этом.
Если вы находитесь в организации, в которой разные люди имеют полномочия над разными схемами, я считаю хорошей практикой дать другой схеме возможность отключить или даже удалить и воссоздать ваше ограничение.
Например, им может потребоваться отбросить или усечь их таблицу, а затем перезагрузить ее, чтобы обрабатывать некоторые (очень странные) проблемы с поддержкой. Если вы не хотите, чтобы вас вызвали посреди ночи, я рекомендую дать им возможность временно удалить ваше ограничение. (Я также рекомендую настраивать собственные оповещения, чтобы вы знали, отключены ли какие-либо из ваших внешних ограничений). Когда вы пересекаете линии организации/схемы, вы хотите хорошо играть с другими. Индекс, о котором говорил Винсент, является еще одной частью этого.
Одной из причин этого может быть проблема: вам нужно быть осторожным, чтобы удалить вещи в правильном порядке. Это может быть хорошим или плохим в зависимости от того, насколько важно никогда не иметь сирот в ваших таблицах.