Nadużywanie / prawidłowe używanie schematów?

Zadawszy to pytanie na Stackoverflow , zastanawiałem się, gdzie to, co zrobiłem, jest poprawne / najlepsza praktyka.

Zasadniczo każdy obiekt, który tworzę, przechodzi w schemat z nazwą schematu odzwierciedlającą użycie. Na przykład mam schematy Auditi Admin(między innymi).

To z kolei nie pozostawia żadnych przedmiotów dbo. Czy to jest ok? Czy jest coś jeszcze, co muszę zrobić?

Schematy są nie tylko doskonałym narzędziem bezpieczeństwa (co jest wystarczającym powodem do ich użycia), ale są również idealne do logicznej separacji. I wygląda na to, że to właśnie ćwiczysz.

Nawet jeśli obecne wymaganie nie wymaga specjalnych zabezpieczeń, powiedzmy, że wszystkie obiekty bazy danych związane z inspekcją powinny być zabezpieczone do roli bazy danych. Jeśli te obiekty zostały rozproszone w całym dboschemacie, musisz jawnie denyzezwolić na poszczególne obiekty. Ale ze Auditschematem robisz singiel denyi jesteś gotowy.

Osobiście ćwiczę stosowanie schematów. Tak jak wszystkie rzeczy w bazach danych, istnieje też szczęśliwy środek przekazu. Nie stworzyłbym schematu dla każdego szczegółowego aspektu warstwy danych. Istnieje coś takiego jak zbyt wiele schematów i separacji. Ale zgaduję, że nie jesteś blisko tego.

Typowy wzór jest schematy oparte na uprawnieniach, więc trzeba było WebGUI, Desktopetc dla kodu więc wszystkie obiekty mają te same sekcji publicznej ze schematu .

Jeśli masz jasne grupy użytkowników, możesz na to zezwolić, ale w pewnym momencie skończysz z nakładającymi się i niechlujnymi uprawnieniami. Mam tendencję do odraczania kontroli użytkowników / grup do niektórych kontroli wewnątrz kodu, a nie obiektów uprawnień: powiedzmy, że masz użytkowników Admin i HR Excel: wszystkie uruchamiają Desktopkod.

Dane te są zwykle dzielone tak, że mam Dataschematu, może Historylub Archiveschematu.

Niektóre kody nie są publiczne (jak UDF lub wewnętrzny proc), więc użyłbym Helperschematu dla kodu, który nie powinien być uruchamiany przez kod klienta.

Wreszcie, jak schematy Staginglub Systemczy Maintenancesą przydatnymi czasami.

Chociaż w dboschemacie nie ma żadnych obiektów użytkownika , użytkownik dbojest właścicielem wszystkich schematów.

Żadne obiekty w dboschemacie nie są idealnie w porządku. Z tego, co widzę, nie jest to również nadużywanie schematów - chociaż ile schematów to „zbyt wiele” jest dość subiektywnym pytaniem (jest porównywalne do „Ile klas powinien mieć mój projekt OO?”).

Jedyną rzeczą, o której wspomnę, byłoby przyznanie uprawnień do schematu, a nie pojedynczych obiektów (twoje pytanie SO nie określa niczego na temat uprawnień).

Chciałbym użyć schematów do oddzielenia bazy danych według modułów i wzorców użytkowania. Uważam, że bardzo łatwo jest zrozumieć tabele bazy danych, dlatego konserwacja staje się łatwiejsza. Miałem następujące typy schematów w moim ostatnim projekcie serwera SQL. LT - Tabele przeglądowe

COMMON
LT_COMMON
MODULENAME1
LT_MODULENAME1
..

W przypadku dużych modułów rozdzieliliśmy je również na więcej schematów. Na przykład moduł personelu składa się z ponad 5 modułów.

PERSONEL_COMMON
PERSONEL_FINANCE
PERSONEL_MODULE2
..
LT_PERSONEL_COMMON
LT_PERSONEL_FINANCE
LT_PERSONEL_MODULE2

Uwzględniliśmy również schematy dotyczące innych działań TEMP, KONSERWACJA. W studiu zarządzania można filtrować według nazwy schematu. Deweloper odpowiedzialny za MODULE1, filtruje według nazwy i działa prawie cały czas tylko z tymi tabelami. Dzięki temu programiści, dbas i nowi użytkownicy bardzo łatwo mogą zrozumieć tabele bazy danych.

Najlepsze praktyki mogą być inne dla serwera SQL niż dla Oracle, jednak z mojego doświadczenia wynika, że ​​im mniej schematów, tym lepiej.
Lubię mieć schemat dla dba / programisty, który ma specjalne uprawnienia i trochę kodu do obsługi. Wszystkie dane biznesowe powinny iść w jednym schemacie, abyś wiedział, gdzie to jest. Konwencje nazewnictwa są wystarczające, aby rozróżnić użycie tabeli lub przechowywanego kodu.
Widzę przypadek, w którym masz wiele jednostek biznesowych, które mają różne dane, przy niewielkim nakładaniu się, każdy z nich ma własny schemat. W przeciwnym razie zachowaj prostotę.