Schemat, właściciel obiektów w MS SQL

Question

Domyślnie obiekty (tabele, procedury składowane itp.) Są konfigurowane z właścicielem/schematem dbo (myślę, że ms sql 2000 nazywa to właścicielem, podczas gdy ms sql 2005 nazywa to schematem)

Właściciel/schemat naprawdę jest rolą lub użytkownikiem w bazie danych. Zawsze zostawiałem domyślną wersję dbo, ale ostatnio widziałem kilka przykładów w szkoleniowych podręcznikach Microsoftu, gdzie niektóre z ich procedur przechowywanych miały różnych właścicieli/schematy. Kiedy jest to korzystne i dlaczego?

Answer 1

Korzystanie z schematów jest wyjątkowo korzystne, gdy występują obawy dotyczące bezpieczeństwa.

Jeśli masz wiele aplikacji mających dostęp do bazy danych, możesz nie chcieć dać działowi logistyki dostępu do rekordów zasobów ludzkich. Dlatego wszystkie tabele zasobów ludzkich są umieszczane w hr schemacie i zezwalaj na dostęp tylko dla użytkowników w roli hr.

Po sześciu miesiącach Logistics musi teraz znać wewnętrzne konta wydatków, aby móc wysłać wszystkie palety niebieskich długopisów do właściwych osób. Następnie można utworzyć procedurę składowaną, która jest wykonywana jako użytkownik, który ma uprawnienia do przeglądania schematu hr, a także schemat logistyki. Użytkownicy logistyki nigdy nie muszą wiedzieć, co dzieje się w dziale HR, ale wciąż otrzymują swoje dane.

Schematów można również używać w sposób sugerowany przez cfeduke i używać ich do grupowania rzeczy w przeglądarce obiektów. Jeśli to robisz, po prostu bądź ostrożny, ponieważ możesz w końcu stworzyć Person.Address i Company.Address, kiedy naprawdę potrzebujesz pojedynczego dbo.Address (nie wybijam twojego przykładu, cfeduke, tylko użyję go do zilustrowania, że ​​zarówno tabele adresów mogą być takie same lub mogą być inne i YMMV).

Answer 2

Organizacja

W środowisku dev, kopia produkcja obiektów są dbo ale programiści mogą rozwijać się w swoich własnych schematów. Wtedy kod może odwoływać się do prod copy lub ich zmian w bardzo prosty sposób. Używanie aliasów może uczynić tę technikę jeszcze prostszą.

---

Również baza produkcyjna może obsługiwać wiele systemów i podsystemów. Możesz użyć różnych schematów, aby zachować te obiekty pogrupowane.

Answer 3

W SQL 2000 Schemas, gdzie równoważne z użytkownikami baz danych, w SQL 2005 każdy schemat jest odrębną przestrzenią nazw, która istnieje niezależnie od użytkownika bazy danych, który ją utworzył.

Używam schematów, gdy potrzebuję tworzyć funkcje lub moduły, które mogą być wykorzystane później w innych projektach, więc będę mógł wyizolować obiekty bazy danych, które są używane przez moduł.

Answer 4

Używałem schematów w przeszłości w podobny sposób do przestrzeni nazw, więc mogłeś mieć wiele obiektów o nazwie Adres ([Person].[Address], [Company].[Address]). Zaletą tego jest wizualna organizacja w SQL Management Studio, można uzyskać to samo, umieszczając wszystko pod jednym schematem i tabele nazw z jednym identyfikatorem (tj. [dbo].[PersonAddress]).

Używałem ich również do programowania deweloperów i deweloperów przed uruchomieniem SQL Server Developer Edition na wszystkich naszych urządzeniach (z powrotem, gdy mieliśmy wcześniej scentralizowaną bazę programistyczną).

Answer 5

This article wyjaśnia to dobrze, w tym zmiany z SQL Server 2000 do 2005.