🚀 go-pugleaf

W dniu 2018-02-20 o 19:59, Krzysztof Szyszka pisze:
>> > Jeśli nałożymy indeks na tę kolumnę to szukanie będzie błyskawiczne, 
>> niezależnie od tego czy > dane w tej kolumnie będą sekwencyjne.
>> Wyszukiwanie będzie szybsze, ponieważ użyty zostanie indeks.
>> Ale nie zostanie użyte wyszukiwanie w indeksie, tylko skanowanie 
>> indeksu. Taka to drobna różnica...
>> Oczywiście to i tak lepiej niż full-scan-table, ale gorzej niż 
>> index-seek.
> 
> Tak sobie czytam te wasze rozważania i mam kilka uwag:
> 
> Dlaczego uważasz, że "nie zostanie użyte wyszukiwanie w indeksie, tylko 
> skanowanie indeksu"?
> Przecież po to zakłada się indeks na danym polu, żeby wyszukiwać po 
> indeksie, bo indeks z założenia jest zawsze sekwencyjny,
Czepiłem się właśnie wartości *niesekwencyjnych* dla indeksów, zwłaszcza 
klastrowych - czyli PK.
A takie założenie zmienia postać rzeczy, prawda?

Naprawdę nie chce mi się tłumaczyć niuansów, zwłaszcza osobom którym 
przecież działa.
No i na zdrowie.

> a głównym kosztem wyszukiwania po indeksie jest czas porównania 
> indeksowanych wartości, który zawsze będzie większy dla
> stringów, niż dla prostego INT.
Nie chodzi o wielkość danych sensu stricte, ale oczywiście to też ma 
znaczenie.

> Skoro wartości w kolumnie są sekwencyjne, to indeks założony na tej 
> kolumnie będzie powielał kolejność rekordów w tabeli.
Generalnie tak, ale niekoniecznie.
Poza tym, dlatego na samym początku pisałem o wartościach generowanych 
przez rosnącą funkcję monotoniczną - przeoczyłeś?

> Zyskiem podczas wyszukiwania jest odczyt indeksu o mniejszych 
> rozmiarach, zamiast odczytu pełnych rekordów z tabeli.
> Natomiast aktualizacja takiego indeksu po dodaniu nowych rekordów będzie 
> szybsza, bo jedynie dopisujemy kolejne wartości
> na końcu bez konieczności przebudowywania indeksu na początku, czy w 
> środku i według mnie to jest jedyny zysk ze stosowania
> sekwencyjnego PK, ale to będzie odczuwalne dopiero przy naprawdę dużych 
> tabelach.
Zakładasz wartości sekwencyjne dla indeksu.
Ja pisałem o przypadku dokładnie odwrotnym bo taki to został podniesiony 
jako super-duper rewelacja na wartości dla PK.

A to g...o prawda!

> I jeszcze jedno osobiste pytanie: dlaczego wybrałeś jako PK typ 
> rzeczywisty, a nie np. BIG INT (Int64), na którym mógłbyś
> dokonać takiego samego podziału na numer z bazy danych i numer z 
> licencji, a przy porównaniach powinien być szybszy?
Dlaczego szybszy, skoro mój typ to nie jakiś tam float, a 
stałoprzecinkowy, który jest reprezentowany jako Int64 (e.g. Currency w 
Delphi) właśnie?

A poza tym, tak  mi się zwyczajnie wydawało wygodniej.

-- 
wloochacz