Czy to zły pomysł, aby tworzyć obce klucze w tabelach w różnych schematach w tej samej bazie danych dla dużych aplikacji?

Pracuję nad przeniesieniem dużej aplikacji internetowej pl / sql na serwer dedykowany. Ta aplikacja znajduje się w jednym schemacie z 70 pakietami kodu programu. Ta aplikacja została złożona około 15 osób w różnym czasie. I było dla nas normalną praktyką tworzenie obcych kluczy w tabelach referencyjnych w różnych schematach, ponieważ jest to naprawdę wygodne i utrzymuje bazę danych bardzo czystą, ponieważ nie musimy utrzymywać tych samych tabel referencyjnych w różnych schematach.

Ale w każdym razie moja DBA (która utworzyła nową instancję za pomocą DB i skopiowała moją aplikację do strefy Solaris) powiedziała dziś bardzo surowo: „Klucze obce na różnych schematach są złe i musisz je zniszczyć!”. Nie wyjaśnił swojego punktu widzenia.

Czy to naprawdę zły pomysł, aby robić to z dużymi aplikacjami?

Niedźwiedzie ze mną - pochodzę z SQL Server i nienawidzę wyroczni, ale myślę, że argumentacja nadal obowiązuje.

Schematy dobrze izolują tabele od podsystemów logicznych. Klucze obce gwarantują integralność danych. Są to pojęcia ortogonalne - ponieważ oczywiście integralność danych między podsystemami jest również niezbędna. Księgowość i wysyłka oraz ewentualnie dane centralnego klienta nie znajdują się w silosach, w których klient może zostać usunięty podczas korzystania z księgowości.

Dlatego uważam, że wymóg DBA jest oznaką niekompetencji. Proszę, każdy może się zgłosić i przedstawić kontrargument - byłbym szczęśliwy. Ale tak to robię na SQL Server (chociaż znowu nasza definicja schematu to IIRC MAŁO różniąca się od definicji wyroczni).

Żądanie zniszczenia ograniczeń klucza obcego bez szczegółowego uzasadnienia jest głupie, ale warto zachować kontrolę nad zewnętrznymi odnośnikami. Co się stanie, jeśli schematy, do których się odwołujesz, mają inną nazwę na nowym serwerze?

W Oracle rozwiązujesz ten problem, tworząc SYNONIMY dla obiektów, które znajdują się poza bieżącym schematem.

Jeśli potrzebujesz (spacja / bezpieczeństwo / cokolwiek) przeniesienia dowolnego schematu do innej bazy danych, nie będziesz już w stanie obsługiwać referencji. To prawdopodobnie główny powód, dla którego należy poprosić o zabicie referencji.

Jedynym „złym pomysłem”, jaki mogę sobie wyobrazić, jest to, że nie możesz przyznać uprawnienia do obiektu ODNIESIENIA (potrzebnego do utworzenia ograniczenia odnoszącego się do tabeli) do roli. Muszę być zrobiony schemat / użytkownik przez schemat / użytkownik.

Poza tym nie widzę sensu twojego DBA.

Pomyśl o tym: schemat właściciela tabeli potomnej zaczyna tworzyć rekord w swojej tabeli i nieświadomie uniemożliwia użytkownikowi schematu tabeli nadrzędnej usuwanie rekordów z tabeli nadrzędnej. Czy to coś, co przewiduje i docenia?