Jakie są dobre schematy SQL Server?

Nie jestem początkującym w korzystaniu z baz danych SQL, aw szczególności z SQL Server. Jednak przede wszystkim byłem facetem SQL 2000 i zawsze byłem zdezorientowany przez schematy w 2005+. Tak, znam podstawową definicję schematu, ale do czego są one naprawdę używane w typowym wdrożeniu programu SQL Server?

Zawsze używałem domyślnego schematu. Dlaczego miałbym chcieć tworzyć specjalistyczne schematy? Dlaczego miałbym przypisywać którykolwiek z wbudowanych schematów?

EDYCJA: Aby to wyjaśnić, chyba szukam korzyści ze schematów. Jeśli zamierzasz używać go tylko jako schematu bezpieczeństwa, wygląda na to, że role bazy danych już wypełniały tę ... eee ... um ... rolę. Używanie go jako specyfikatora przestrzeni nazw wydaje się być czymś, co można zrobić z własnością (dbo kontra użytkownik itp.).

Chyba chodzi mi o to, co robią schematy, których nie można zrobić z właścicielami i rolami? Jakie są ich szczególne korzyści?

Schematy logicznie grupują tabele, procedury, widoki razem. Wszystkie obiekty związane z pracownikami w employeeschemacie itp.

Możesz także nadać uprawnienia tylko jednemu schematowi, aby użytkownicy widzieli tylko schemat, do którego mają dostęp, i nic więcej.

Podobnie jak Przestrzeń nazw kodów C #.

Mogą również zapewnić rodzaj ochrony przed kolizją nazw dla danych wtyczek. Na przykład nowa funkcja zmiany przechwytywania danych w SQL Server 2008 umieszcza tabele, których używa, w osobnym schemacie cdc. W ten sposób nie muszą się martwić konfliktem nazw między tabelą CDC a rzeczywistą tabelą używaną w bazie danych, a w związku z tym mogą celowo ukrywać nazwy prawdziwych tabel.

Wiem, że to stary wątek, ale sam przejrzałem schematy i sądzę, że poniższe przykłady mogą być kolejnym dobrym kandydatem do użycia schematu:

W magazynie danych, w którym dane pochodzą z różnych źródeł, możesz użyć innego schematu dla każdego źródła, a następnie np. Kontrolować dostęp na podstawie schematów. Pozwala również uniknąć możliwych kolizji nazw między różnymi źródłami, ponieważ inny plakat odpowiedział powyżej.

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

Przykład: rozważ system, który wykonuje rejestrowanie. Wszystkie tabele rejestrowania i SP znajdują się w schemacie [rejestrowanie]. Rejestrowanie jest dobrym przykładem, ponieważ rzadko (jeśli w ogóle) inne funkcje w systemie nakładałyby się (czyli łączą się) na obiekty w schemacie rejestrowania.

Wskazówka dotycząca korzystania z tej techniki - należy ustawić inny ciąg połączenia dla każdego schematu w aplikacji / systemie. Następnie wdrażasz elementy schematu na nowym serwerze i zmieniasz parametry połączenia, gdy potrzebujesz skalować.

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

W skrócie ... schematy nie są zbyt przydatne, z wyjątkiem bardzo specyficznych przypadków użycia. Sprawia, że ​​bałagan. Nie używaj ich, jeśli możesz pomóc. I staraj się przestrzegać zasady K (eep) I (t) S (imple) S (tupid).

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

Większość osób początkowo łączy konta użytkowników z bazami danych za pomocą ról. Gdy tylko przypiszesz użytkownika do sysadmin lub do roli db_owner roli bazy danych, w dowolnej formie, konto to jest aliasowane do konta użytkownika „dbo” lub jest pełne uprawnienia do bazy danych. Kiedy to nastąpi, bez względu na to, jak przypisujesz się do schematu wykraczającego poza domyślny schemat (który ma taką samą nazwę jak twoje konto użytkownika), te prawa dbo są przypisywane do obiektu, który tworzysz w ramach użytkownika i schematu. To trochę bezcelowe ..... tylko przestrzeń nazw i dezorientuje prawdziwą własność tych obiektów. Jego kiepski projekt, jeśli mnie zapytasz ... ktokolwiek go zaprojektował.

To, co powinni byli zrobić, to utworzyć „Grupy”, wyrzucić schematy i role i po prostu pozwolić ci na grupowanie grup grup w dowolnej kombinacji, którą lubisz, a następnie na każdym poziomie powiedzieć systemowi, czy uprawnienia są dziedziczone, odrzucane lub zastępowane niestandardowymi te. Byłoby to o wiele bardziej intuicyjne i pozwoliłoby DBA lepiej kontrolować, kim są prawdziwi właściciele tych obiektów. Obecnie sugeruje się, że w większości przypadków domyślny użytkownik SQL Server programu dbo ma te prawa .... nie użytkownika.

W sklepie ORACLE, w którym pracowałem przez wiele lat, schematy były używane do enkapsulacji procedur (i pakietów), które dotyczyły 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” dotyczył aplikacji programistycznej / konfiguracyjnej do użytku wyłącznie przez programistów. Kolejnym schematem „API” był dostęp do danych klienta za pośrednictwem widoków i procedur (wyszukiwania). Kolejny kod zamknięty w schemacie „API”, który został użyty do synchronizacji danych programistycznych / konfiguracyjnych i klienta z aplikacją, która ma własną bazę danych. Niektóre z tych schematów „API”, pod osłonami, nadal miałyby ze sobą wspólne procedury i funkcje (za pośrednictwem innych „WSPÓLNYCH”

Powiem, że brak schematu prawdopodobnie nie jest końcem świata, choć może być bardzo pomocny. Naprawdę, to brak pakietów w SQL Server, który naprawdę stwarza problemy w moim umyśle ... ale to inny temat.

Myślę, że schematy są jak wiele nowych funkcji (czy to SQL Servera, czy innego narzędzia programowego). Musisz dokładnie ocenić, czy korzyść z dodania go do zestawu programistycznego kompensuje utratę prostoty w projektowaniu i implementacji.

Wydaje mi się, że schematy są mniej więcej równoważne opcjonalnym przestrzeniom nazw. Jeśli znajdujesz się w sytuacji, w której kolidują nazwy obiektów, a stopień szczegółowości uprawnień nie jest wystarczający, oto narzędzie. (Chciałbym powiedzieć, że mogą istnieć problemy z projektowaniem, którymi należy się zająć na bardziej podstawowym poziomie).

Problem może polegać na tym, że jeśli tak się stanie, niektórzy programiści zaczną używać go do krótkoterminowych korzyści; a kiedy już tam jest, może stać się kudzu.

W SQL Server 2000 utworzone obiekty zostały połączone z tym konkretnym użytkownikiem, np. Jeśli użytkownik powie, że Sam tworzy obiekt, powiedzmy Pracownicy, ta tabela wyglądałaby następująco: Sam.Employees. Co jeśli Sam opuści firmę lub przeprowadzi się do innego obszaru działalności. Gdy tylko usuniesz użytkownika Sama, co stanie się z tabelą Sam.Employees? Prawdopodobnie musiałbyś najpierw zmienić właściciela z Sam.Employees na dbo.Employess. Schemat zapewnia rozwiązanie tego problemu. Sam może stworzyć cały swój obiekt w schemacie takim jak Emp_Schema. Teraz, jeśli stworzy obiekt Pracownicy w Emp_Schema, wówczas obiekt będzie nazywany Emp_Schema.Employees. Nawet jeśli konto użytkownika Sam musi zostać usunięte, nie wpłynie to na schemat.

rozwój - każdy z naszych deweloperów ma własny schemat gry w piaskownicy.

Oto dobry przykład implementacji użycia schematów z SQL Server. Mieliśmy kilka aplikacji z dostępem typu ms. Chcieliśmy przekonwertować je na portal aplikacji ASP.NET. Każda aplikacja MS-Access jest zapisywana jako aplikacja dla tego portalu. Każda aplikacja MS-Access ma własne tabele bazy danych. Niektóre z nich są powiązane, umieszczamy je we wspólnym schemacie dbo programu SQL Server. Reszta otrzymuje własne schematy. W ten sposób chcemy wiedzieć, które tabele należą do aplikacji w portalu aplikacji ASP.NET, które można łatwo nawigować, wizualizować i utrzymywać.