Mam do czynienia z następującym problemem. Mam bardzo duży stół. Ta tabela jest dziedzictwem osób, które wcześniej pracowały nad projektem. Tabela znajduje się w MS SQL Server.

Tabela ma następujące właściwości:

ma około 300 kolumn. Wszystkie z nich mają typ „tekstowy”, ale niektóre z nich w końcu powinny reprezentować inne typy (na przykład liczbę całkowitą lub datetime). Trzeba więc przekonwertować te wartości tekstowe na odpowiednie typy przed ich użyciemtabela ma ponad 100 rzędów miliomów. Przestrzeń dla tabeli wkrótce osiągnie 1 terabajttabela nie zawiera żadnych indeksówtabela nie ma żadnych zaimplementowanych mechanizmów partycjonowania.

Jak można się domyślić, nie można uruchomić żadnego rozsądnego zapytania do tej tabeli. Teraz ludzie wstawiają tylko nowe rekordy do tabeli, ale nikt ich nie używa. Muszę to zrestrukturyzować. Planuję utworzyć nową strukturę i uzupełnić nową strukturę danymi ze starej tabeli. Oczywiście wdrożę partioning, ale nie jest to jedyna rzecz do zrobienia.

Jedną z najważniejszych cech tabeli jest to, że te pola, które są czysto tekstowe (tj. Nie muszą być konwertowane na inny typ) zazwyczaj mają często powtarzane wartości. Zatem rzeczywista różnorodność wartości w danej kolumnie mieści się w zakresie 5-30 różnych wartości. To skłania do idealizacji normalizacji: dla każdej takiej kolumny tekstowej utworzę dodatkową tabelę z listą wszystkich różnych wartości, które mogą pojawić się w tej kolumnie, a następnie utworzę klucz podstawowy (tinyint) w tej dodatkowej tabeli i następnie użyje odpowiedniego klucza obcego w oryginalnej tabeli zamiast przechowywać te wartości tekstowe w oryginalnej tabeli. Następnie umieści indeks w tej kolumnie klucza obcego. Liczba kolumn do przetworzenia w ten sposób wynosi około 100.

Rodzi następujące pytania:

czy ta normalizacja rzeczywiście zwiększyłaby prędkość kolejek nakładających warunki na niektóre z tych 100 pól? Jeśli zapomnimy o rozmiarze potrzebnym do zachowania tych kolumn, czy nastąpiłby wzrost wydajności ze względu na podstawienie początkowych kolumn tekstowych kolumnami tinyint? Jeśli nie wykonam żadnej normalizacji i po prostu umieścisz indeks na tych początkowych kolumnach tekstowych, czy wykonanie będzie takie samo jak dla indeksu na planowanej kolumnie tinyint?Jeśli wykonam opisaną normalizację, zbudowanie widoku pokazującego wartości tekstowe będzie wymagało dołączenia do mojego głównego stołu przy użyciu około 100 dodatkowych tabel. Pozytywnym momentem jest to, że zrobię te połączenia dla par „klucz podstawowy” = „klucz obcy”. Jednak wciąż należy połączyć dużą liczbę stołów. Oto pytanie: czy wydajność zapytań skierowanych do tego widoku w porównaniu z wydajnością zapytań do początkowej nie znormalizowanej tabeli nie będzie gorsza? Czy SQL Server Optimizer naprawdę będzie w stanie zoptymalizować zapytanie w sposób, który pozwala na czerpanie korzyści z normalizacji?

Przepraszam za taki długi tekst.

Dzięki za każdy komentarz!

PS Stworzyłem powiązane pytanie dotyczące łączenia 100 tabel;Łączenie 100 tabel