🚀 go-pugleaf

W dniu 2018-02-20 o 11:30, zpksoft pisze:
/ciach/

> Owa sekwencyjność jest moim zdaniem przereklamowana.
A to zdanie opierasz na czym?
Zaklinaniu?

> Nawet jeśli pole typu integer stanowi indeks unikalny to wcale nie oznacza, że nie możemy wrzucić do bazy dane w kolejności 1, 5, 4, 7, 3.
Możemy, a jakże.
Ale po to się buduje AutoNumer, sekwencje czy generatory, aby tak tego 
nie robić.
To, ze coś można zrobić, nie oznacza, że tak powinno się robić.
Tłumaczę od wczoraj, dlaczego nie powinno się tak tego robić.
Ale grochem o ścianę - przecież Wam działa błyskawicznie, tzn. jest 
super-duper.
Otóż - nie jest.

> Najważniejsza jest unikalność.
Skoro tak uważasz, to mam dla Ciebie propozycję.
Zrezygnuj z Primary Key i załóż tylko ograniczenie na unikalność 
wartości pola.

> To nie określone pole jest indeksem tylko dla określonego pola możemy zdefiniować indeks. 
Indeks posiada wartości z pola, na podstawie którego jest zbudowany. 
Tworzony jest przyrostowe wg dodawanych wartości do tabeli wg pola.
Dlatego tak ważna jest sekwencyjność danych dla wartości pól dla indeksu 
Primary Key.

> Oznacza to tyle, że baza oprócz naszej kolumny w tabeli przechowuje oddzielnie również swój porządek.
> Najłatwiej przekonać się o tym wywołując select na zwykłej kolumnie łańcuchowej.
> Baza będzie szukać długo.
> 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.
A to jest ciut dalej od "błyskawicznie".
A to z kolei oznacza, że nawet nie rzuciłeś okiem na linki, które 
podesłałem.

-- 
wloochacz