„Dobra praktyka” to jedno z tych wyrażeń, które pozwalają nam sprawić, by nasze uprzedzenia wydawały się ważniejsze niż są w rzeczywistości...
Ogólnie rzecz biorąc, chcesz przechowywać razem rzeczy, które należą do siebie. Jeśli masz jeden system informatyczny, który obsługuje wszystko dla firmy, a podmioty, którymi zarządzasz, są ze sobą powiązane – klienci mają zamówienia, zamówienia mają sprzedawców i produkty – możesz argumentować, że należą do siebie. Jeśli, z drugiej strony, zauważysz, że masz „wyspy” stołów, które tak naprawdę nie łączą się z żadnymi innymi stołami, być może nie pasują do siebie.
Z punktu widzenia konserwacji, zarządzanie większą liczbą baz danych oznacza więcej kopii zapasowych, więcej procedur konserwacji i więcej profili bezpieczeństwa do zarządzania.
Z punktu widzenia czytelności, polowanie na różne bazy danych w celu znalezienia interesującej Cię tabeli jest prawdopodobnie złą rzeczą – na przykład, gdy istnieje tabela łączenia „wielu do wielu” między „klientami” a „pracownikami” – np. zespół sprzedaży - gdzie mieszka ten stół? W bazie danych „klient” czy „pracownik”?
Z punktu widzenia niezawodności nie jestem pewien, czy można wymusić ograniczenia klucza obcego w bazach danych.
Naprawdę nie mogę wymyślić żadnych korzyści płynących z tego - więc powiedziałbym, że to zły pomysł.
