🚀 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? 
Performance!

> PK ma za zadanie gwarantować
> unikalność i to jest jego fundamentalna cecha. 
Tak, ale co wyszukiwaniem danych?
A wyszukiwanie to również złączenia.

> 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?
No naprawdę...

Pierwsze z brzegu:
https://tomharrisonjr.com/uuid-or-guid-as-primary-keys-be-careful-7b2aa3dcb439

Krótko: fragmentacja, a to nas prowadzi do kolejnych wniosków:
https://blog.sqlauthority.com/2007/03/30/sql-server-index-seek-vs-index-scan-table-scan/

itd. itp.

W każdej bazie jest mniej więcej podobnie.

Poza tym, Paweł pisze o tym, że taki YT ma coś jak UUID jako klucz. Nie 
wydaje mi się. Wydaje mi się, że na zewnątrz jest to UUID, ale wewnątrz 
systemu jest to inna wartość (np. Int64), która nie jest eksponowana na 
zewnątrz.
Ale w sumie nie mam na moje "wydaje się" dowodów na to i nie chce mi się 
szukać.

-- 
wloochacz