W jaki sposób używanie oddzielnych schematów wpływa na wydajność programu SQL Server 2008?

Chcę używać osobnych schematów dla obiektów o różnych celach w naszej bazie danych SQL Server 2008. Obecnie używamy dość nazbyt odrętwiającej konwencji nazewnictwa, aby wskazać cel tabeli lub procedury składowanej, a przedrostki oznaczają, że musimy przeskanować pięć lub sześć znaków x, zanim jeszcze zobaczymy początek unikalnej nazwy. Chciałbym użyć osobnych schematów dla tabel, które są po prostu używane do sterowania interfejsem użytkownika (menu, role według osoby itp.) Oraz dla tabel, które są tabelami wymiarów vs. tabel faktów itp.

Moje pytanie brzmi: czy będzie miało wpływ na wydajność przy użyciu wielu schematów (schematów?) W przeciwieństwie do starego dobrego dbo do wszystkiego?

Może to mieć wpływ na wydajność optymalizatora zapytań, choć niewielki, w zależności od stylu kodowania. Jeśli odwołujesz się do tabeli bez schematu, optymalizator musi najpierw spróbować zidentyfikować tabelę, sprawdzając tabele w domyślnym schemacie użytkownika (jeśli taki istnieje), a następnie używając dbo., A następnie wszystko inne. Jeśli jawnie odwołujesz się do tabel jako schema.table, co i tak jest prawdopodobnie dobrą praktyką, nawet tego niewielkiego narzutu można uniknąć.

Bez różnicy w wydajności. Jednak używasz teraz schematów (nawet jeśli go nie znasz).

Zastosowanie odwołań do obiektów schematu, takich jak tabele, procedury składowane, UDF itp., Które nie są zakwalifikowane do schematu , ma wpływ na wydajność. Referencje powinny zawsze być kwalifikowane według schematu. Takie niekwalifikowane odniesienia muszą zostać rozwiązane, a dzieje się tak:

• Najpierw poszukaj obiektu o tej samej nazwie i typie w domyślnym schemacie użytkownika, na podstawie którego poświadczenia została ustanowiona sesja (np jsmith.). Jeśli zostanie znaleziony, używana jest ta instancja.
• W przeciwnym razie poszukaj obiektu o tej samej nazwie i typie pod schematem dbo.

Ma to kilka efektów:

• W większości przypadków potrzebne są dwa wyszukiwania, aby rozstrzygnąć odwołanie, zamiast pojedynczego wyszukiwania, jeśli odwołanie jest zakwalifikowane do schematu.
• Plan wykonania uzyskany po związaniu zapytania / procedury składowanej / funkcji zdefiniowanej przez użytkownika nie może być buforowany i ponownie używany.

Ostatnim efektem, który można znaleźć - boleśnie - gdy coś się psuje, jest to, że różni użytkownicy mogą uzyskać różne wyniki z danego zapytania lub procedury składowanej. Coś takiego select * from foo join barmoże działać dobrze dla mnie jako właściciela bazy danych; może być uszkodzony dla użytkownika, jsmithktóry nieumyślnie lub nie, utworzył tabelę nazwaną na foopodstawie własnego schematu ( jsmith.foo) w tej samej bazie danych.

Z tego powodu też, createi dropoświadczenia powinny schematu zakwalifikować nazwę tworzonego obiektu lub spadła.