🚀 go-pugleaf

W dniu 2018-02-19 o 18:28, Roman Tyczka pisze:
> On Mon, 19 Feb 2018 17:36:02 +0100, wloochacz wrote:
>
>>> Początkowo, właściwie dla prób wykorzystywałem GUID. Ten brak sekwencyjności nie bardzo mi przeszkadzał bo user pyta zwykle o różną kolejność danych.
>> Skoro tak piszesz, to chyba nie do końca rozumiesz jak działa baza
>> relacyjna.
>>
>>> Chciałem zbudować uniwersalny ID łańcuchowy w którym zakodowany byłby czas i losowość. Udało mi się opracować identyfikator 12 znakowy np. wygenerowany w tym momencie: "1OeS9r2JykUj". Mogę z niego odczytać czas powstania z dokładnością do dwóch milisekund. Czas zawarty jest w członie "1OeS9r". Stosuję te identyfikatory mniej więcej od czerwca 2005 roku i jeszcze nigdy w żadnej bazie nie miałem błędu powstania dwóch takich samych identyfikatorów.
>> Unikalność to nie problem, ale co z sekwencyjnością?
>
> Tak z ciekawości... po co sekwencyjność w PK? PK ma za zadanie gwarantować
> unikalność i to jest jego fundamentalna cecha. Baza i tak jak potrzeba to
> ma jakieś kolumny z timestampem czy innym kluczem trzymającym sekwencyjność
> w jakimś kontekście typu data urodzenia, data sprzedaży, numer kolejny
> dokumentu sprzedaży itp. Po co więc tak bardzo forsujesz konieczność
> posiadania sekwencyjności w PK?
>

O ile dobrze pamiętam to np w MSSQL rekordy tabeli są ułożone wg klucza 
głównego i wg niego dzielone na strony.
Gdy wstawiasz nowy rekord z PK > max(PK) to się po prostu dopisuje na 
końcu, jeśli min(PK) < PK < max(PK) to rekord wstawiany jest w środek i 
dane trzeba przesuwać, często wstawiać nowe strony w środek tabeli, a to 
mocno wpływa na wydajność i powoduje dużą fragmentację bazy (co też 
wpływa na wydajność).

GUID (sekwencyjny czy nie) ma jeszcze jedną dużą wadę - rozmiar. Przez 
duży rozmiar w cache mieści znacznie mniej informacji (np o joinach) i 
serwer częściej musi sięgać do danych fizycznych na dysku.

Pozdrawiam