Czy jeśli używa się UUID, to ID w postaci longa/inteagera generowanego przez bazę danych jest już niepotrzebne?
0
4
Jeśli chodzi o czystość: nie ma sensu, lepiej mieć jeden id niż dwa oznaczające to samo.
Jeśli chodzi o wydajność to może mieć to sens, gdy nie używasz kolumny uuid jako klucz czy jako indeks. Przez swoją losowość UUID słabo współgra z b-tree, są nawet rozszerzenia, które to minimalizują https://github.com/tvondra/sequential-uuids jak i nowe formaty UUID https://www.ietf.org/archive/id/draft-peabody-dispatch-new-uuid-format-01.html
2
Sampeteq napisał(a):
Czy jeśli używa się UUID, to ID w postaci longa/inteagera generowanego przez bazę danych jest już niepotrzebne?
A z jakich motywacji myslisz o tym UUID ?
Argumenty ZA Uuid / Guid widzę ze 2-3, wiele więcej za Id
a) UUid jest generowany przez libkę do perzystencji (Hibernate), i jest określony jeszcze przed zapisem. Wprawdze jak po ludzku się buduje powiazania obiektów Hibertane, nie jest to potrzebne, ale z rzadka się przyda (hardkorzy kodujacy obiekt obcy jako int zamiast referencji, taka "optymalziacja" która zabija sens używania hibernate)
b) jest taki schemat włamu / nadużycia apki webowej, która ujawnia id, np http:alamakota/invoices?id=17 przez wbicie nastepnej liczby uzyskuje wgląd w fakturę, w która by wglądu nie miał - jeśli tam w URL jest Uuuid, włam jest niemal niemożliwy
c) bardzo wyrafinowane i niszowe zagadnienia serializacji / transferu rekordów do innej bazy
Wiecej argumentów za uuid nie przypominam sobie
tabela z id, mozna na to liczyć, gdy się nie poda order by przy odczycie, jest zwykle w miare "estetycznie" posortowana
wydajność itd... wiele przemawia za id
slsy napisał(a):
Jeśli chodzi o czystość: nie ma sensu, lepiej mieć jeden id niż dwa oznaczające to samo.
Ma sens miec dwa w przypadku b)
0
slsy napisał(a):
Przez swoją losowość UUID słabo współgra z b-tree
A jeśli ma się UUIDa rosnącego w czasie? Pamiętam że w Cassandze był taki algorytm generowania UUIDa że górna część to był czas a dolna część to był IPik komputera (czy jakoś tak). Dzięki temu UUID był zawsze rosnący
UPDATE chyba UUID - Version 1
1
@robertos7778: Ten indeks musi być zmaterializowany do jakiejś fizycznej formy na dysku. Dopisanie czegoś na końcu indeksu jest tańsze niż dopisanie czegoś w środku. Jeszcze większy problem będziesz mieć jeżeli założysz indeks klastrowy na kluczu głównym, bo będzie konieczna nie tylko przebudowa indeksu, ale i danych.
0
Nie lubię ID generowanego przez bazę, ponieważ oznacza to, że moja encja w początkowym etapie jest jakby niekompletna - brakuje jej ID. W Javie to jeszcze przejdzie, bo wszystko może być nullem (chociaż muszę się pilnować, żeby użyć instancji zwróconej z repozytorium) i nawet nie zauważę, ale np. w Kotlinie oznacza to, że wszędzie muszę się uganiać z typem nullowalnym. Repozytorium nie musi też zwracać zapisanej encji, mam "kontrolę" nad generowaniem ID w testach (przydało się, chociaż pewnie dało się lepiej to zrobić).
0
@piotrpo:
To już są szczegóły implementacyjne, która każda baza może realizować inaczej. Przecież dopisanie "w środku" nie oznacza, że trzeba rozpychać indeks i przepisywać jego fragmenty. Można dodać kolejny "blok" indeksu z N liśćmi, a jego adres dopisać do węzła drzewa powyżej, który i tak musi znać lokalizację swoich węzłów (liści)-dzieci. Minus indeksu zapisywanego w sposób losowy to operacja range-scan na takim indeksie, no ale nie po to się go tworzy w taki sposób, żeby sąsiednie klucze leżały obok siebie.
Jeśli często sięgamy do sąsiednich kluczy lub skanujemy ich zakresy to lepsze są klucze generowane po kolei.
Ale jeśli mamy dużo odczytów po kluczu unikalnym lub prawie-unikalnym i mamy równocześnie wiele sesji to robiących, to klucze losowo trafiające w strukturę drzewa pozwolą na rozłożenie obciążenia pod kątem I/O. Oczywiście zakładając, że warstwa fizyczna posiada wiele urządzeń, które równocześnie mogą być odczytywane. Jak pod spodem będzie jeden dysk, to będzie gorzej.