Jakie są najlepsze praktyki korzystania ze schematów w SQL Server?

Rozumiem możliwości schematów SQL Server, ale jakie są najlepsze praktyki? Pewnie, że dają one kolejną warstwę bezpieczeństwa i zapewniają logiczne grupowanie obiektów bazy danych w bazie danych, ale co tam jest typowe? Z mojego doświadczenia często nie widzę wykorzystywanych wielu niestandardowych schematów. Czy to jest typowe? Czy jest to rzadszy scenariusz, w którym należy stosować schematy niestandardowe?

Używamy ich

• aby oddzielić uprawnienia dla klienta (np. mamy schematy pulpitu, WebGUI itp.)
• do logicznego grupowania np. (Schematy danych i pomostowe dla naszych tabel).

Przydatne i praktyczne spostrzeżenia dotyczące białej księgi wspomnianej przez Mariana:

• GRANT na schemacie: nie ma więcej uprawnień na obiekt. Nowy proces w schemacie WebGUI automatycznie ma uprawnienia do schematu
• Ładne zgrupowania w SSMS Object Explorer
• OBJECT_SCHEMA_NAME
• Jesteś zmuszony zakwalifikować nazwy obiektów (co jest najlepszą praktyką)

Myślę, że odpowiedź można znaleźć w tym artykule MSDN: Najlepsze praktyki SQL Server - Implementacja schematów obiektów bazy danych .

Cytat: „W białej księdze omówiono możliwości ulepszenia administracji bezpieczeństwa bazy danych użytkowników i przedstawiono kilka najlepszych praktyk dotyczących korzystania ze schematów do zarządzania obiektami baz danych w bazach danych programowania i produkcji. W szczególności omawia trzy scenariusze w świecie rzeczywistym:

• Ochrona obiektów bazy danych przed modyfikacją przez użytkowników bez wiedzy właściciela bazy danych
• Zapobieganie bazowym obiektom bazy danych, w szczególności bazom niezależnych dostawców oprogramowania (ISV), przed dostępem ad hoc lub nieprawidłowym dostępem użytkownika prowadzącym do niskiej wydajności aplikacji
• Łączenie powiązanych grup obiektów (bytów logicznych) w jednej fizycznej bazie danych w celu zmniejszenia obciążenia administracyjnego fizycznej bazy danych ".

Szczególnie korzystam z trzeciej części - powiązania grupy obiektów razem na podstawie ich logicznego znaczenia - różnych schematów należących do różnych projektów w tej samej bazie danych.

Możesz zajrzeć do niektórych podstawowych tekstów na ten temat, aby odpowiedzieć na niektóre pytania. Dokumenty dotyczące modelu relacyjnej bazy danych od EF Codd i CJ Date dotyczą wielu typowych pytań związanych z projektowaniem, wydajnością, bezpieczeństwem, optymalnym projektowaniem schematów itp. Ostatecznie, jako ojcowie nowoczesnego modelu relacyjnych baz danych, ich prace stanowią podstawę dla DB2, ORACLE, SQL Server (Microsoft i Sybase), Ingres, MySQL i każdy inny dostępny zestaw relacyjnych baz danych.