MS SQL - wydajność

Mam takie pytanie z punktu widzenia trochę bardziej świadomego użytkownika.
Czy jeśli jest tabela w której umieszczone są dokumenty finansowe różnych typów (powiedzmy 10 typów - faktura, korekta, wezwanie do zapłaty itd)
i w tej tabeli występuje kolumna z określeniem typu dokumentu
i ten typ opisany jest ciągiem znaków, a nie liczbą np 'faktura' 'korekta' zamiast 01,02,
to czy ma to wpływ na wydajność bazy? Zaznaczę przy tym, że dokumentów są dziesiątki lub wręcz setki tysięcy.

Z góry dzięki za odpowiedź.

Może mieć, w końcu wybieranie większej ilości danych trwa krócej niż mniejszej, a porównywanie napisów trwa dłużej niż porównywanie liczb.

Oczywiście ma to wpływ.

Prosty przykład - jeśli masz typ dokumentu określony liczbą powiedzmy - tinyint (zakres 0-255), bo więcej niż 255 różnych typów dokumentów nie przechowujesz, taki typ zabiera ci raptem 1 bajt.

Jeśli masz varchar - w którym słownie określasz typ np "korekta", "faktura","wezwanie" etc. to zajmujesz dopowiednio więcej danych.

Idąc dalej, ilosć wierszy na stronie z danymi jest mniejsza im więcej bajtów dany wiersz zajmuje. Czyli to też się przekłada bezpośrednio na liczbę odczytów, miejsca alokowanego w pamięci RAM aż w końcu do ruchu sieciowego :). Takie sytuacje mogą wystąpić jak masz słabo znormalizowany system (poczytaj o normalizacji baz danych )

Jak to się mówi grosz do grosza ..... :) Z drugiej strony nie dramatyzowałbym z tego powodu jakoś strasznie , choć jestem mocno przeciwny rozrzutności i niechlujności w projektach :)

Jeżeli taki problem dotyczy tylko jednej kolumny, a kolumn masz w tej tabeli 100, to zapewne różnica wydajności samych odczytów tej tabeli będzie niewielka.

Nie powinieneś tego robić w ten sposób, ponieważ umieszczasz w bazie mnóstwo nadmiarowych danych, potencjalnie niespójnych. Niech no ktoś zrobi literówkę, dodając dokument do bazy - i co wtedy? Dokument znika, bo nie jest widoczny pod żadnym znanym typem. Jest to błąd projektowy, a baza danych nie jest 3NF (http://pl.wikipedia.org/wiki/Posta%C4%87_normalna_%28bazy_danych%29). W takich sytuacjach robi się słownik - dodatkową tabelę, trzymającą wszystkie możliwe typy dokumentów, oraz klucz obcy pomiędzy identyfikatorem typu w tej tabeli a typem dokumentu w dużej tabeli.

Inna sprawa, że do pewnego momentu taki błąd projektowy nie będzie mieć większego wpływu na wydajność. Dane w indeksach są wyszukiwane binarnie, ilość porównań jest bardzo mała w stosunku do ilości danych. Jednak jeśli baza danych urośnie, to indeks spuchnie, a większy indeks to więcej danych do trzymania w pamięci, więcej danych do modyfikowania w przypadku insertów i update'ów, dłuższe czasy dostępu itp. Przy czym taka sytuacja (czyli nieduży spadek wydajności przy niedużej ilości danych) będzie tylko przy dobrze zaprojektowanych indeksach, czego nie spodziewałbym się po złamaniu 3NF.

Dziękuję bardzo, od początku mi się to nie podobało, a Wy potwierdziliście moje obawy. Wzmiankowana tabela rośnie o 10-12 tys rekordów miesięcznie, a system docelowo ma spełniać jeszcze wiele innych funkcji. To może być jedno z wielu wąskich gardeł, muszę sobie w wolnej chwili popatrzeć na tą bazę dokładniej. A tak na marginesie to potwierdzacie słowa Einsteina „Jeśli nie potrafisz wytłumaczyć czegoś w prosty sposób, to znaczy, że tak naprawdę tego nie rozumiesz”.

FInalnie jak juz bedziesz mial bardzo duzo danych zamien tabele na widok skladajacy sie z takiej ilosci tabel jaka ilosc typow dokumentow (zalozny ze sa 2)

 
create view schemat.dokumenty as 
  select * from schemat.dokumenty_1
  union all
  select * from schemat.dokumenty_2

dodajesz do kazdej z tabel checkconstraint np dla 1 ze typ dokumentu = 1 a dla drugiej ze 2.

Co to daje?

Jesli bedziesz mial rozny rozklad danych wg typu moze sie okazac ze bedziesz otrzymywal calkowicie inne plany zapytania przy zlaczeniach z innymi obiektami.
Dodatkowo bedziesz mogl osobno sobie je poindexowac.