Jak w temacie, powiedzmy że projektując obecnie aplikację webową jakie podejście było by odpowiedniejsze?
Zasadniczo mam na myśli silnik MySQL/MariaDB ale nie wykluczam innych, chciałbym poruszyć temat - wiem że na stacku jest go multum, ciekawi mnie opinie na 4p.
0
1
przede wszystkim tracisz kolejność - nie pobierzesz ostatnich 100 rekordów, nie posortujesz wg kolejności dodania, nie wybierzesz zakresu. Dodatkowo dochodzi kwestia wydajności - zarówno jeśli chodzi o porównanie wartości jak i miejsce, jakie zajmują na dysku. Poza tym nie wiem jak inni ale ja nie jestem w stanie zapamiętać całego GUID aby go gdzieś np. przepiać a inta już jak najbardziej tak :). Oczywiście GUID mają nie tylko wady ale i zalety - chyba największą zaletą jest "globalna" unikalność co ma niebagatelne znaczenie przy systemach rozproszonych
2
Z jakiego języka i frameworku (np perzystencyjnego) operujesz z bazą?
Baza w wersji single, czy jakies cloudy? Bo to ważne
W jednym z ERPów które bardzo szanuję UUIDa mają rekordy zdolne do samodzielnego istnienia, czyli faktura tak, ale pozycje faktury nie.
Przydatne, gdy taki obiekt się chce eksportować na zewnątrz, i spójnie zaimportować (np po jakimś czasie jego aktualizację, i chcemy, aby nie powieliła a zastąpiła)
Tabele, które mają UUIDa nadal mają ID.
Integerowy klucz to podstawa, za UUIDem trzeba mieć dodatkowe argumenty/motywację.
W kręgach javowskich "modne", bo zagadnienie eqals/hashCode dla obiektów JPA jeszcze nie zapisanych, nie ma klarownego rozwiązania.
Moim zdaniem projekt udoskonalonego widelca v17.3 do zupy.
0
Przykład "z życia":
ShopSys DB
Ostatnio miałem z nim trochę styczność, wiele też doczytałem iż trzymanie takiego identyfikatora w kolumnie binarnej bez pk ale jako indeks znacząco poprawia performance takiej bazy.
Jak na razie rozwiązanie wspomniane przez @AnyKtokolwiek brzmi najlepiej.
1
Zawsze możesz mieć zwykłe id jako klucz podstawowy + UUID jako pole dodatkowe, np. żeby móc porównywać encje w ORM.