Ist es eine schlechte Idee, für große Anwendungen Fremdschlüssel in den Tabellen in einem anderen Schema in derselben Datenbank zu erstellen?

Ich arbeite an der Übertragung einer großen webbasierten pl / sql-Anwendung auf den dedizierten Server. Diese Anwendung befindet sich in einem Schema mit 70 Paketen Programmcode. Dieser Antrag wurde ca. 15 Personen zu unterschiedlichen Zeiten gestellt. Es war für uns üblich, Fremdschlüssel in den Referenztabellen in verschiedenen Schemata zu erstellen, da dies sehr praktisch ist und die Datenbank sehr sauber hält, da wir nicht dieselben Referenztabellen in verschiedenen Schemata aufbewahren müssen.

Mein DBA (der eine neue Instanz mit DB erstellt und meine Anwendung innerhalb der Solaris-Zone kopiert hat) sagte jedoch heute sehr hart: "Fremdschlüssel in den verschiedenen Schemata sind böse und müssen zerstört werden!". Er hat seinen Standpunkt nicht erklärt.

Ist es wirklich eine schlechte Idee, dies mit großen Anwendungen zu tun?

Bearwith me - Ich komme aus SQL Server und hasse Orakel, aber ich denke, die Argumentation steht noch.

Schemata sind nett, um Tabellen von logischen Subsystemen zu isolieren. Fremdschlüssel gewährleisten die Datenintegrität. Hierbei handelt es sich um orthogonale Konzepte, da natürlich auch die Datenintegrität zwischen Subsystemen ein Muss ist. Buchhaltung und Versand und möglicherweise zentrale Kundendaten befinden sich nicht in Silos, in denen ein Kunde gelöscht werden kann, während er in der Buchhaltung verwendet wird.

Als solches denke ich, dass die Anforderung des DBA ein Zeichen der Inkompetenz ist. Bitte kann jeder einspringen und Gegenargumente vorbringen - ich würde mich freuen. Aber so mache ich es auf SQL Server (obwohl unsere Definition des Schemas IIRC ein KLEINES ist, das sich von der Oracle-Definition unterscheidet).

Die Vernichtung von Fremdschlüsseleinschränkungen ohne detaillierte Begründung zu fordern, ist zwar töricht, aber es ist sinnvoll, die externen Referenzen unter Kontrolle zu halten. Was ist, wenn die Schemas, auf die Sie verweisen, auf Ihrem neuen Server einen anderen Namen haben?

In Oracle lösen Sie dieses Problem, indem Sie SYNONYMS für Objekte erstellen, die außerhalb des aktuellen Schemas liegen.

Wenn Sie ein Schema (Speicherplatz / Sicherheit / was auch immer) in eine andere Datenbank verschieben müssen, können Sie die Verweise nicht mehr verarbeiten. Dies ist wahrscheinlich der Hauptgrund für die Aufforderung, die Referenzen zu töten.

Die einzige "schlechte Idee", die ich mir dabei vorstellen kann, ist, dass Sie einer Rolle nicht das REFERENCES-Objektprivileg (das zum Erstellen einer Einschränkung, die auf eine Tabelle verweist) erteilen können. Ich muss Schema / Benutzer für Schema / Benutzer erledigen.

Außerdem verstehe ich nicht, worum es bei Ihrem DBA geht.

Stellen Sie sich Folgendes vor: Das Besitzerschema der untergeordneten Tabelle beginnt, einen Datensatz in seiner Tabelle zu erstellen, und verhindert unwissentlich, dass der Benutzer des übergeordneten Tabellenschemas Datensätze aus der übergeordneten Tabelle löscht. Ist es etwas, was es vorwegnimmt und schätzt?