Postgres i indeksy

0

Mam tabelę, która zawiera ok. 150 tysięcy rekordów.
Jej struktura to ID, kolumna z jakimś numerem seryjnym i do tego 2-3 kolumny z jakimiś tekstami/opisami (niezbyt długimi - po kilkadziesiąt znaków).

Ważne - tabela jest stworzona, zapełniona i potem tylko odpytywana. Odpytywanie będzie miało miejsce jedynie po numerze seryjnym - czyli użytkownik wprowadza ten numer, a SQL ma zwrócić stringi do niego przypisane. Dlatego (wprawdzie 150 tys to nie jest jakaś kosmiczna ilość) aż się prosi o założenie indeksu na kolumnie z kodem.

I teraz moje pytanie - jak uważacie, czy lepiej zrobić tą kolumnę jako varchar czy int? Kody mają 6 albo 7 znaków (jedynie cyfry - dlatego można to zapisać w postaci liczbowej), poza znalezieniem i wyrzuceniem do raportu, nic z tym się nie dzieje, więc z punktu widzenia aplikacji, typ danych kolumny z kodami nie ma żadnego znaczenia. Tutaj chodzi jedynie o to, żeby maksymalnie szybko działało wyszukiwanie.

Wydaje mi się, że lepszą opcją będzie zrobienie tego w postaci numerycznej niż tekstowej, ale chciałem poprosić Was o potwierdzenie, albo wyprowadzenie z błędu. Poszukałem w necie i w oparciu o te informacje także mam wrażenie, że int jest słuszniejszy, ale to może być tak jak z samochodem - kupujesz Focusa i nagle wszędzie widzisz Fordy na ulicach ;)

1

jedynie cyfry - dlatego można to zapisać w postaci liczbowej

Z ciekawości: pesel zapisałbyś jako bigint czy varchar? :-)

0

Zależy od potrzeb i innych czynników - czy np. będzie on jakoś walidowany, czy jedynie zapisany w bazie, co będzie się z nim potem działo, w jaki sposób będzie przetwarzany itp., aczkolwiek ponieważ ten PESEL, wprawdzie jest cyfrowy, ale nie będzie traktowany jako liczba, a do tego ma stałą długość, raczej bym się skłaniał do zapisu jako char(11).

Tylko różnica jest taka, że w moim przypadku zależy mi jedynie na tym, żeby szukanie działało jak najsprawniej i żeby najłatwiej było bazie przeszukiwać indeks. Dlatego to może być zapisane w dowolnej postaci, z mojego punktu widzenia nie ma to znaczenia, ale (jak pisałem) z tego co znalazłem, to łatwiej jest przelecieć indeks b-tree na wartościach liczbowych.

2

wprawdzie jest cyfrowy, ale nie będzie przetwarzany jako liczba

Czy Twoje numery seryjne będą przetwarzane jako liczba? Ponieważ z postu wynika, że nie.

w moim przypadku zależy mi jedynie na tym, żeby szukanie działało jak najsprawniej i żeby najłatwiej było bazie przeszukiwać indeks

Liczby będą minimalnie szybsze, lecz wchodzimy tutaj w teren premature optimization.

0

Nie, to chodzi jedynie o znalezienie odpowiedniej wartości w tabeli i pobranie przypisanych do nich wartości. Przyjmijmy, że mamy tabelę z kolumnami numer katalogowy, producent, model, opis. Użytkownik podaje numer katalogowy, a SQL zwraca producenta, model i opis. Nic się z tym dziać nie będzie, jak napisałem - tabela zostanie jednorazowo zapełniona danymi, a potem będzie tylko odczytywana. I powtarzam - to, czy ten numer seryjny będzie tekstem czy liczbowo dla mnie nie ma żadnego znaczenia, jedynie chodzi o to, żeby założony na tej kolumnie indeks działał jak najsprawniej.

1

jedynie chodzi o to, żeby założony na tej kolumnie indeks działał jak najsprawniej

W takim razie załóż indeks liczbowy.

1

Jeśli to są numery zamówień, to upewnij się że użytkownicy nie mogą sobie nawzajem podglądać nieswoich zamówień.
Bo takie niebezpieczeństwo występuje gdy zamówienie / fv generujesz na podstawie numeru sekwencyjnego.
Można się przed tym zabezpieczyć (np. sprawdzając zawsze też nr klienta pytającego o dane).

0

Nie, to nie są żadne poufne dane, z grubsza chodzi o to, co napisałem 2 posty wyżej. Taki katalog, który na podstawie oznaczenia ma wczytać informacje o przedmiocie. Każdy korzystający z aplikacji ma mieć dostęp do tego bez jakichkolwiek ograniczeń.

3

znacznie więcej zyskasz jeśli zamiast indeksu liczbowego założysz indeks na wszystkie kolumny po których będziesz szukał + kolumny, które będziesz wyciągał. W Twoim przypadku to będzie indeks na numer katalogowy, producent, model, opis. Wtedy silnik w ogóle nie będzie musiał odwoływać się do tabeli a skoro insertów i tak nie będzie to nie będzie to miało znaczenia dla wydajności dodawania danych (poza pierwszym)

0

No ale wydaje mi się, że jak już baza ustali ID, dla którego ma pobrać dane, to później już ich odczyt z tabeli to formalność. Największym problemem jest przeszukanie tych 100 tysięcy wpisów - bez indeksów to trzeba przelecieć przez wszystkie po kolei i tego chciałem uniknąć. Pytanie - czy indeksy na wszystkich kolumnach mają sens? Jeśli tak, to nie ma problemu i mogę tak zrobić, tylko jakoś nie jestem przekonany, czy to coś da.

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