MS SQL - wydajność

0

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ź.

0

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.

1

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 :)

0

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.

1

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%87normalna%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.

0

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”.

0

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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0