Predkosc czy miejsce

Podczas pracy z MySQL, warto wiedziedziec o mozliwosci wplyniecia na wydajnosc bazy, juz na etapie projektowania jej struktury. W zaleznosci od zasobow ktorymi dysponujemy, mozemy zaprojektowac baze tak, aby dane w niej przechowywane zajmowaly jak najmniej miejsca, lub tak, aby wzrosla wydajnosc.

Model I - oszczedzamy miejsce
Podczas projektowania struktury bazy danych, wybieramy taki typ pol, aby zminimalizowac przestrzen dyskowa potrzebna do przechowywania danych. Jednym z typow pol pozwalajacych na oszczednosc miejsca jest VARCHAR. Rozmiar danych zapisanych w tym polu to L+1 bajtow, gdzie L to dlugosc danych zapisanych w kolumnie. Tak wiec 'string' zajmuje 6+1 = 7 bajtow (6 na zapisanie danych + 1 na oznaczenie konca danych).

Model II - zwiekszamy wydajnosc
Jezeli zastapimy pole typu VARCHAR (np. VARCHAR(30)) polem typu CHAR (tu: CHAR(30)), zwiekszy sie ilosc przestrzeni dyskowej potrzebnej na zapisanie danych. Pole typu CHAR zawsze zajmuje maksymalna ilosc przestrzeni dyskowej - tu 30 bajtow. Jezeli dane wstawione do takiego pola sa mniejsze niz 30 bajtow (np. 6), sa uzupelniane spacjami. To wyraznie zwieksza objetosc danych.

Jednak wykorzystanie modelu II niesie za soba znaczne zwiekszenie szybkosci wyszukiwania danych. Kazdy rekord zajmuje zawsze tyle samo miejsca, latwiej jest wiec wyszukac szukany rekord (aby odnalesc poczatek rekordu w pliku danych, wystarczy przemnozyc nr rekordu przez jego dlugosc). W przypadku modelu I nie jest to juz takie proste, gdyz wczesniejsze rekordy zajmuja rozna ilosc miejsca.

Podczas pracy z MySQL nalezy pamietac, ze rekord powinien zawierac wyszystkie pola typu CHAR (ogolnie: pola o stalej dlugosci) lub VARCHAR (oglonie: o zmiennej dlugosci). Jezeli tabela zawiera juz pole typu VARCHAR, to podczas dodawania pola CHAR zostanie ono dodane jako VARCHAR. Dlaczego? Otoz wstawienie pola CHAR nie zmieni formatu rekordu na staly gdyz istnieja w nim inne pola o zmiennej dlugosci. Nie niesie wiec za soba korzysci. Natomiast wstawienie pola VARCHAR zmniejszy ilosc potrzebnego miejsca. Dlatego podczas projektowania tabeli, nalezy wybrac odpowiadajacy nam model i konsekwentnie wybierac wymagane typy pol.

Niejednokrotnie jestesmy zmuszeni do umieszczenia w tabeli pola ktorego typ nie ma stalej dlugosci (np. TEXT) i nie mozemy uzyskac rekordu o stalej dlugosci. W takim przypadku warto rozwazyc przeniesienie pol o zmiennej dlugosci do innej tabeli (np. w przypadku forum, w jednej tabeli mozna przechowywac "metadane" wpisu - tytul, daty, id autora itd, a w drugiej sama tresc). Jednak takie rozwiazanie nalezy dobrze przemyslec w kontekscie projektu gdyz moze w rezultacie pogorszyc wydajnosc.

Inna wada Modelu I jest to co znamy z systemu plikow FAT - fragmentacja danych zapisywanych w pliku podczas edycji lub dodawania rekordow.
Uzycie Modelu II nie tylko nie powoduje fragmentacji danych, ale niesie za soba takze inne korzysci - prawdopodobienstwo naprawienia uszkodzonej tabeli jest o wiele wieksze, jezeli rekordy maja stala dlugosc.