Co dobre są schematy SQL Server?
Nie jestem początkujący w używaniu baz danych SQL, a w szczególności SQL Server. Jednak byłem przede wszystkim SQL 2000 facet i zawsze byłem zdezorientowany schematów w 2005+. Tak, znam podstawową definicję schematu, ale do czego tak naprawdę są one używane w typowym wdrożeniu SQL Server?
Zawsze używałem domyślnego schematu. Dlaczego miałbym chcieć tworzyć specjalistyczne Schematy? Dlaczego miałbym przypisać dowolny z wbudowanych schematów?
EDIT: dla wyjaśnienia, 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ż to wypełniły.. er.. um.. rola. A używanie go jako określnika przestrzeni nazw wydaje się być czymś, co można było zrobić z własnością (dbo versus user, itp..).
Chyba chodzi mi o to, co robią Schematy, których nie można zrobić z właścicielami i rolami? Jakie są ich konkretne zalety?
11 answers
Schematy logicznie grupują tabele, procedury, widoki razem. Wszystkie obiekty związane z pracownikami w schemacie employee
itp.
Możesz również nadać uprawnienia tylko jednemu schematowi, aby użytkownicy mogli zobaczyć tylko schemat, do którego mają dostęp i nic więcej.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-01-11 08:54:42
Podobnie jak Przestrzeń nazw kodów C#.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-09-06 08:28:16
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.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-07-12 15:03:32
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.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-12-16 07:29:49
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ć.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-12-27 18:33:21
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).
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2018-03-14 00:13:11
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.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-10-22 22:01:06
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.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-11-02 18:47:01
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.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-09 18:48:17
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.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-06-28 06:45:52
Rozwój-każdy z naszych programistów otrzymuje własny schemat jako piaskownicę do zabawy.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2009-02-09 17:53:44