Indeksowane widoki i łączenie w lewo raz na zawsze

Korzystam z MSSQL Server 2008 R2 i próbuję zoptymalizować moje widoki, gdy natknąłem się na widoki indeksowane. Niestety większość moich widoków używa lewych połączeń zewnętrznych, które nie są obsługiwane w widokach indeksowanych. Po wielu badaniach, jestem zdezorientowany najlepszym sposobem na to. Widzę to w następujący sposób:

1) Konwertuj lewe złączenia na wewnętrzne złączenia za pomocą sztuczki, aby symulować lewe sprzężenie z „OR (IsNull (a) AND IsNull (b))”

Znalazłem to rozwiązanie w kilku miejscach, ale wspomniano o utracie wydajności.

2) Konwertuj lewe połączenia na wewnętrzne połączenia i zastąp puste wartości null pustych kolumn pustymi przewodnikami (00000000-0000-0000-0000-000000000000) i dodaj pojedynczy wiersz w prawej tabeli z pasującym przewodnikiem.

Wydaje się to najbardziej oczywiste pod względem wydajności, ale wydaje się stratą miejsca dla każdego wiersza, który w przeciwnym razie byłby NULL.

3) Przerwij mój widok na dwa widoki. Pierwszy widok to większość mojej logiki, którą można indeksować. Drugi widok pochodzący z pierwszego widoku i dodający lewe sprzężenia.

Chodzi o to, że indeksowany może być przyrost wydajności poprzez indeksowanie widoku podstawowego. A nawet odpytywanie widoku pochodnego przyniosłoby przynajmniej część korzyści związanych z wydajnością.

4) Nie indeksuj moich widoków

Czy pozostawienie widoku w taki sposób, w jaki jest bardziej skuteczne niż jakakolwiek z powyższych opcji?

5) Pomysł, o którym nie pomyślałem

Mój podstawowy scenariusz napisałem w następujący sposób:

<code>   CREATE TABLE [dbo].[tbl_Thumbnails](
        [ThumbnailId] [uniqueidentifier] NOT NULL,
        [Data] [image] NULL,
        [Width] [smallint] NOT NULL,
        [Height] [smallint] NOT NULL
     CONSTRAINT [PK_tbl_Thumbnails] PRIMARY KEY CLUSTERED 
    (
        [ThumbnailId] ASC
    )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
    ) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

    GO

    CREATE TABLE [dbo].[tbl_Tags](
        [TagId] [uniqueidentifier] NOT NULL,
        [ThumbnailId] [uniqueidentifier] NULL
     CONSTRAINT [PK_tbl_Tags] PRIMARY KEY CLUSTERED 
    (
        [TagId] ASC
    )WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
    ) ON [PRIMARY]

    GO

    CREATE VIEW [dbo].[v_Tags] WITH SCHEMABINDING AS
    SELECT     dbo.tbl_Tags.TagId, dbo.tbl_Tags.ThumbnailId
    FROM         dbo.tbl_Tags LEFT OUTER JOIN
                          dbo.tbl_Thumbnails
    ON     dbo.tbl_Tags.ThumbnailId = dbo.tbl_Thumbnails.ThumbnailId

    GO

    INSERT INTO tbl_Tags VALUES ('16b23bb8-bf17-4784-b80a-220da1163584', NULL)
    INSERT INTO tbl_Tags VALUES ('e8b50f03-65a9-4d1e-b3b4-268f01645c4e', 'a45e357b-ca9c-449a-aa27-834614eb3f6e')
    INSERT INTO tbl_Thumbnails VALUES ('a45e357b-ca9c-449a-aa27-834614eb3f6e', NULL, 150, 150)
</code>

Teraz wykonanie następującej kwerendy: „Nie można utworzyć indeksu w widoku„ Test.dbo.v_Tags ”, ponieważ używa ono połączenia LEWO, PRAWO lub PEŁNE ZEWNĄTRZ, a żadne widoki ZEWNĘTRZNE nie są dozwolone w widokach indeksowanych. „:

<code>CREATE UNIQUE CLUSTERED INDEX [TagId] ON [dbo].[v_Tags] 
(
[TagId] ASC
)
GO 
</code>

Jest to oczekiwane zachowanie, ale jaki sposób postępowania zaleciłby uzyskanie najlepszej wydajności w moim scenariuszu? Punktem wyjścia jest tutaj najlepsza wydajność.

questionAnswers(1)

yourAnswerToTheQuestion