Est-ce une mauvaise idée de créer des clés étrangères sur les tables dans des schémas différents dans la même base de données pour les grandes applications?

Je travaille sur le transfert d'une grosse application web pl / sql vers le serveur dédié. Cette application est située dans un schéma avec 70 packages de code de programme. Cette demande a été déposée auprès d'environ 15 personnes à différentes époques. Et c'était une pratique normale pour nous de créer des clés étrangères sur les tables de référence dans différents schémas car elle est vraiment pratique et maintient la base de données très propre, car nous n'avons pas besoin de conserver les mêmes tables de référence dans des schémas différents.

Mais quoi qu'il en soit, mon DBA (qui a créé une nouvelle instance avec DB et copié mon application à l'intérieur de la zone Solaris) a dit très dur aujourd'hui: "Les clés étrangères sur les différents schémas sont mauvaises et vous devez les détruire!". Il n'a pas expliqué son point de vue.

Est-ce vraiment une mauvaise idée de faire ça avec une grosse application?

Restez avec moi - je viens de SQL Server et je déteste Oracle, mais je pense que l'argumentation est toujours valable.

Les schémas sont pratiques pour isoler les tables des sous-systèmes logiques. Les clés étrangères garantissent l'intégrité des données. Ce sont des concepts orthogonaux - comme il est évident que l'intégrité des données entre les sous-systèmes est également indispensable. La comptabilité et l'expédition et éventuellement les données centrales des clients ne vivent pas dans des silos où un client peut être supprimé tout en étant utilisé dans la comptabilité.

En tant que tel, je pense que l'exigence du DBA est un signe d'incompétence. Je vous en prie, n'importe qui peut intervenir et fournir un contre-argument. Mais c'est ainsi que je le fais sur SQL Server (bien que, encore une fois, notre définition du schéma soit IIRC un PEU différent de la définition d'Oracle).

Tout en exigeant la destruction des contraintes de clés étrangères sans raisonnement détaillé est stupide, il est logique de garder les références externes sous contrôle. Que faire si les schémas auxquels vous faites référence sont nommés différemment sur votre nouveau serveur?

Dans Oracle, vous résolvez ce problème en créant des SYNONYMES pour les objets qui sont en dehors du schéma actuel.

Si vous avez besoin (espace / sécurité / autre) de déplacer un schéma vers une autre base de données, vous ne pourrez plus gérer les références. C'est probablement la principale raison de demander la suppression des références.

La seule "mauvaise idée" que j'imagine en faisant cela, c'est que vous ne pouvez pas accorder le privilège d'objet REFERENCES (celui nécessaire pour créer une contrainte qui fait référence à une table) à un rôle. Je dois faire le schéma / utilisateur par schéma / utilisateur.

En plus de cela, je ne vois pas l'intérêt de votre DBA.

Pensez-y simplement: le schéma du propriétaire de la table enfant commence à créer un enregistrement dans sa table et empêche, sans le savoir, l'utilisateur du schéma de la table parent de supprimer des enregistrements de la table parent. Est-ce quelque chose qu'il anticipe et apprécie?