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 cerca de 15 pessoas em momentos diferentes. E era uma prática normal para nós criar chaves estrangeiras nas tabelas de referência em esquemas diferentes 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 DB e copiou meu aplicativo dentro da zona do Solaris) disse muito duramente hoje: "Chaves estrangeiras em diferentes esquemas são más e você precisa destruí-las!". Ele não explicou seu ponto de vista.
É realmente uma má ideia fazer isso com aplicativos grandes?
Os esquemas são bons para isolar tabelas de subsistemas lógicos. As chaves estrangeiras garantem a integridade dos dados. Esses são conceitos ortogonais - já que, obviamente, a integridade dos dados entre os subsistemas também é obrigatória. Contabilidade e remessa e possivelmente dados centrais do cliente não vivem em silos onde um cliente pode ser excluído enquanto é usado na contabilidade.
É assim que faço no SQL Server (embora, novamente, nossa definição de esquema seja IIRC um POUCO diferente da definição do Oracle).
Dessa forma, acho que a exigência do DBA é um sinal de incompetência. T
Embora exigir a destruição de restrições de chave estrangeira sem raciocínio detalhado seja tolice, faz sentido manter as referências externas sob controle. E se os esquemas aos quais você está fazendo referência tiverem nomes diferentes em seu novo servidor?
No Oracle, você resolve esse problema criando SINÔNIMOS para objetos que estão fora do esquema atual.
Se você tiver a necessidade (espaço/segurança/qualquer coisa) de mover algum esquema para um banco de dados diferente, não poderá mais lidar com as referências. Esse é provavelmente o principal motivo para solicitar a eliminação das referências.
A única "má ideia" que posso imaginar ao fazer isso é que você não pode conceder o privilégio de objeto REFERENCES (o necessário para criar uma restrição que se refere a uma tabela) para uma função. Eu tenho que fazer esquema/usuário por esquema/usuário.
Além disso, não vejo o ponto do seu DBA.
Pense nisso: o esquema do proprietário da tabela filho começa a criar registros em sua tabela e, sem saber, impede que o usuário do esquema da tabela pai exclua registros da tabela pai. É algo que antecipa e aprecia?