É má ideia criar chaves estrangeiras nas tabelas em esquemas diferentes no mesmo banco de dados para grandes aplicativos?

Estou trabalhando na transferência de um grande aplicativo baseado na web pl / sql para o servidor dedicado. Este aplicativo está localizado em um esquema com 70 pacotes de código de programa. Esta aplicação foi feita aproximadamente 15 pessoas em diferentes épocas. E era prática normal para nós criar chaves estrangeiras nas tabelas de referência em diferentes esquemas, porque é realmente conveniente e mantém o banco de dados muito limpo, porque não precisamos manter as mesmas tabelas de referência em esquemas diferentes.

Mas, de qualquer maneira, meu DBA (que criou uma nova instância com o DB e copiou meu aplicativo dentro da zona Solaris) disse muito duro hoje: "Chaves estrangeiras nos diferentes esquemas são más e você precisa destruí-las!". Ele não explicou seu ponto de vista.

É realmente péssima fazer isso com grandes aplicativos?

Tenha paciência comigo - venho do SQL Server e odeio a Oracle, mas acho que a argumentação ainda permanece.

Esquema é bom para isolar tabelas de subsistemas lógicos. Chaves estrangeiras garantem a integridade dos dados. Esses são conceitos ortogonais - como obviamente a integridade dos dados entre os subsistemas também é essencial. Contabilidade e remessa e, possivelmente, os dados do cliente central não vivem em silos onde um cliente pode ser excluído enquanto estiver sendo usado na contabilidade.

Como tal, acho que o requisito do DBA é um sinal de incompetência. Por favor, qualquer um pode intervir e fornecer um contra-argumento - eu ficaria feliz. Mas é assim que faço no SQL Server (embora, novamente, nossa definição de esquema seja IIRC um POUCO diferente da definição de oracle).

Embora seja tolo exigir a destruição de restrições de chave estrangeira sem um raciocínio detalhado, faz sentido manter as referências externas sob controle. E se os esquemas que você está referenciando tiverem um nome diferente no seu novo servidor?

No Oracle, você resolve esse problema criando SYNONYMS para objetos que estão fora do esquema atual.

Se você precisar (espaço / segurança / o que for) de mover qualquer esquema para um banco de dados diferente, não poderá mais lidar com as referências. Essa é provavelmente a principal razão para solicitar a eliminação das referências.

A única "má idéia" que posso imaginar ao fazer isso é que você não pode conceder o privilégio do objeto REFERENCES (aquele necessário para criar uma restrição que se refere a uma tabela) a uma função. Eu tenho que ser feito esquema / usuário por esquema / usuário.

Além disso, não vejo o objetivo do seu DBA.

Basta pensar no seguinte: O esquema do proprietário da tabela filho começa a criar registro em sua tabela e, sem saber, impede o usuário do esquema da tabela pai de excluir registros da tabela pai. É algo que antecipa e aprecia?