Co dobre są schematy SQL Server?

Podobnie jak Przestrzeń nazw kodów C#.

Mogą również zapewnić Rodzaj ochrony przed kolizją nazw dla danych wtyczki. Na przykład nowa funkcja przechwytywania danych zmiany w SQL Server 2008 umieszcza tabele, których używa w oddzielnym schemacie cdc. W ten sposób nie muszą się martwić o konflikt nazewnictwa między tabelą CDC a rzeczywistą tabelą używaną w bazie danych i w tym celu mogą celowo zaciemniać nazwy rzeczywistych tabel.

Wiem, że to stary wątek, ale po prostu spojrzałem na Schematy sam i myślę, że poniższy może być kolejnym dobrym kandydatem do użycia schematu:

W Datawarehouse, z danymi pochodzącymi z różnych źródeł, można użyć innego schematu dla każdego źródła, a następnie np. kontrolować dostęp na podstawie schematów. Unika się również ewentualnych kolizji nazewniczych między różnymi źródłami, Jak odpowiedział inny plakat powyżej.

Jeśli zachowasz swój schemat dyskretny, możesz skalować aplikację, wdrażając dany schemat na nowy serwer DB. (Zakłada to, że masz aplikację lub system, który jest wystarczająco duży, aby mieć odrębną funkcjonalność).

Przykładem może być system, który wykonuje logowanie. Wszystkie tabele logowania i SPs znajdują się w schemacie [logging]. Rejestrowanie jest dobrym przykładem, ponieważ rzadko (jeśli w ogóle) zdarza się, że inne funkcje w systemie nakładają się na obiekty w logowaniu schemat.

Podpowiedź do użycia tej techniki -- mieć inny ciąg połączeń dla każdego schematu w aplikacji / systemie. Następnie wdraża się elementy schematu na nowym serwerze i zmienia ciąg połączenia, gdy trzeba skalować.

Zgadzam się z Brentem w tej kwestii... zobacz tę dyskusję tutaj. http://www.brentozar.com/archive/2010/05/why-use-schemas/

W skrócie... Schematy nie są bardzo przydatne, z wyjątkiem bardzo konkretnych przypadków użycia. Robi bałagan. Nie używaj ich, jeśli możesz temu zaradzić. I staraj się przestrzegać zasady K(eep) I(t) S(imple) s (tupid).

Nie widzę korzyści w aliasowaniu użytkowników powiązanych ze schematami. Oto dlaczego....

Większość ludzi łączy swoje konta użytkowników z bazami danych za pomocą ról początkowo, gdy tylko przypisujesz użytkownika do sysadmin lub do db_owner bazy danych, w dowolnej formie, konto to jest aliasowane do konta użytkownika " dbo " lub ma pełne uprawnienia do bazy danych. Gdy to nastąpi, bez względu na sposób przypisania się do schematu poza domyślnym schematem (który ma taką samą nazwę jak użytkownik konto), te prawa dbo są przypisane do tych obiektów, które tworzysz pod swoim użytkownikiem i schematem. To bezcelowe.....i tylko przestrzeń nazw i myli prawdziwą własność tych obiektów. Kiepski projekt....kto to zaprojektował.

To, co powinni zrobić, to utworzyć "grupy" i wyrzucić schematy i role i po prostu pozwolić na warstwy grup grup w dowolnej kombinacji chcesz, a następnie na każdej warstwie powiedzieć systemowi, czy uprawnienia są dziedziczone, odrzucane lub nadpisane niestandardowe. Byłoby to o wiele bardziej intuicyjne i pozwoliło DBA lepiej kontrolować, kto jest prawdziwym właścicielem tych obiektów. Obecnie jego domniemane w większości przypadków domyślnym użytkownikiem SQL Server dbo ma te prawa....Nie użytkownik.

W sklepie ORACLE, w którym pracowałem przez wiele lat, Schematy były używane do hermetyzacji procedur (i pakietów), które miały zastosowanie do różnych aplikacji front-end. Inny schemat " API " dla każdej aplikacji często miał sens, ponieważ przypadki użycia, użytkownicy i wymagania systemowe były zupełnie inne. Na przykład, jeden schemat " API " był przeznaczony dla aplikacji deweloperskiej/konfiguracyjnej, która miała być używana tylko przez programistów. Innym schematem " API " był dostęp do danych Klienta poprzez widoki i procedury (wyszukiwania). Inny schemat' API ' zawierał kod, który był używany do synchronizacji danych programistycznych/konfiguracyjnych i klienta z aplikacją, która miała własną bazę danych. Niektóre z tych schematów "API", pod przykrywką, nadal współdzieliłyby ze sobą wspólne procedury i funkcje (za pośrednictwem innych "wspólnych" schematów), gdzie miałoby to sens.

Powiem, że brak schematu to chyba nie koniec świata, choć może być bardzo pomocny. Tak naprawdę to brak pakietów w SQL serverze sprawia, że naprawdę stwarza problemy w moim umyśle... ale to inny temat.

Myślę, że schematy są jak wiele nowych funkcji (czy to do SQL Server lub jakiekolwiek inne narzędzie programowe). Musisz dokładnie ocenić, czy korzyści z dodania go do zestawu programistycznego rekompensują utratę prostoty w projektowaniu i wdrażaniu.

Wygląda na to, że schematy są mniej więcej równoważne opcjonalnym przestrzeniom nazw. Jeśli znajdujesz się w sytuacji, w której nazwy obiektów kolidują ze sobą, a szczegółowość uprawnień nie jest wystarczająco dobra, oto narzędzie. (Byłbym skłonny powiedzieć, że tam mogą to być kwestie projektowe, które powinny być rozpatrywane na bardziej podstawowym poziomie.)

Problem może być taki, że jeśli tam jest, niektórzy programiści zaczną go używać dla krótkoterminowych korzyści; a gdy już tam będzie, może stać się kudzu.

W SQL Server 2000 utworzone obiekty były powiązane z danym użytkownikiem, np. Sam tworzy obiekt, powiedzmy, pracownicy, że tabela będzie wyglądać jak: Sam.Pracowników. Co? o tym, czy Sam opuszcza compnay lub przenosi się do innego obszaru biznesowego. Jak najszybciej usunąć użytkownik Sam, co by się stało z Samem.Stolik dla pracowników? Prawdopodobnie będziesz musiał zmienić własność najpierw od Sama.Pracowników do dbo.Pracownica. Schema dostarcza rozwiązanie do przezwyciężyć ten problem. Sam can Utwórz cały jego obiekt w schemacie takim jak Emp_Schema. Jeśli utworzy obiekt wewnątrz Emp_Schema, to obiekt będzie określane jako Emp_Schema.Pracowników. Nawet jeśli konto użytkownika Sam musi zostać usunięte, schemat nie zostałby naruszony.

Rozwój-każdy z naszych programistów otrzymuje własny schemat jako piaskownicę do zabawy.