🚀 go-pugleaf

W dniu czwartek, 15 lutego 2018 11:32:40 UTC+1 użytkownik wloochacz napisał:
> W dniu 2018-02-15 o 09:09, zpksoft pisze:
> > W dniu wtorek, 13 lutego 2018 12:24:43 UTC+1 użytkownik Pancio napisał:
> /ciach/
> 
> > W ogóle nie używam identyfikatorów liczbowych. Wyłącznie łańcuchowe. Zero problemów. Jeśli masz wybór to zastanów się nad tym. Bardzo duże bazy są oparte tylko na takich identyfikatorach. Zobacz np. filmiki na Youtube: https://youtu.be/jOqktpxdGxg <- tu ID=jOqktpxdGxg. Nie muszą martwić się że gdzieś w sieci ktoś podwójnie zlicza ID. Dodatkowym atutem jest to że taki identyfikator tworzy klient więc może posłużyć się nim zanim wpisze rekord do bazy (!).
> 
> Jeżeli wartość takiego identyfikatora jest generowana jako rosnąca 
> funkcja monotoniczna, to jest najgorsze z możliwych rozwiązań, jeśli 
> idzie o wydajność.
> 
> Powoduje to poważne problemy z sortowaniem i fragmentacją indeksów. 
> Chcesz mieć pofragmentowany indeks Primary Key - używaj takich 
> identyfikatorów.
> 
> I właśnie dlatego np. w MS SQL jest specjalna funkcja do kreowania 
> GUIDów sekwencyjnych:
> https://docs.microsoft.com/en-us/sql/t-sql/functions/newsequentialid-transact-sql
> 
> -- 
> wloochacz

Lata temu stosowałem GUID do tego celu, ale już od dawna stosuję inne rozwiązanie. U mnie identyfikatory łańcuchowe można by rzec są sekwencyjne, można nawet wyliczyć z nich czas powstania.
Niedawno jedna z baz które obsługuję przekroczyła 1TB i można by rzec że chodzi jak młódka. Ogólnie trudno jest przekonać programistów do tego typu identyfikatorów (bojaźń?). Niedawno miałem za zadanie zsynchronizować dwie bazy, ale w pewnym zakresie. Kilka tabel miało identyfikatory liczbowe. Niesamowitą jazdę z tym miałem bo właśnie liczbowe identyfikatory się powtarzały. Nie obeszło się bez zmian logiki w pluginie którego te tabele dotyczyły.

Paweł