typ dla PK i ekspozycja ID na front

czy jest jakiś argument za tym aby dla PK stosować UUID jeżeli nie jest to system rozproszony? poszedłem tym tropem ale zacząłem się wczytytywać i to kiepski wybór, UUID jest za duży na to, jest problem z wyszukiwaniem po UUID gdy jest PK ze względu na wydajność, klastrowaniem. baza będzie miała milionowe ilości wpisów

jakie widzicie problemy z obszaru SEC gdy na front wrzucane są ID, które są jednocześnie PK w bazie? głównie to zadecydowało o UUID tylko, że w tym momencie UUID też jest PK bo sprawia wrażenie bezpieczniejszego ale nie widać poza tym więcej korzyści

jakiś czas temu też miałem podejście do hybrydowego rozwiązania ale nie widziałem tym bardziej sensu w posiadaniu dwóch ID, często ten drugi nazywany SURROGATE miewa różne definicje i nie to tym bardziej nie czuje, że dobry kierunek

baza postgres, TSID, GUID nie wchodzą w gre ze wzlędu na brak wsparcia z pudełka

Problem z wystawianiem PK jako inkrementowany integer na świat jest taki, że łatwo go zgadnąć, co może budzić niepokój bo ktoś może próbować uzyskać dostęp do danych które nie należą do niego przez wpisywanie kolejnych liczb 3, 4, 5, 6, itd

Z drugiej strony twoja aplikacja powinna mieć system autoryzacji, który za każdym razem sprawdza czy dany użytkownik ma dostęp do żądanej informacji. W przypadku gdy twój system autoryzacji nie ma błędów to takie ID jest bezpieczne, gorzej gdy z jakiegoś powodu wkradnie się tam błąd i uda się obejść zabezpieczenie.

Kolejnym aspektem jest wydajność bazy danych i bazy lepiej sobie radzą z liczbami całkowitymi jako PK a nie losowymi wartościami (UUID), ale to też zależy od silnika. Jedne sobie z tym zagadnieniem radzą lepiej drugie gorzej. Dużo też zależy od ilości danych. Przy małym wolumenie to wpływ na wydajność będzie znikomy, przy milionach rekordów mogą już być kłopoty. Ale znowu dużo zależy od umiejętności bazodanowych i konfiguracji/optymalizacji silnika.

markone_dev napisał(a):

Problem z wystawianiem PK jako inkrementowany integer na świat jest taki, że łatwo go zgadnąć, co może budzić niepokój bo ktoś może próbować uzyskać dostęp do danych które nie należą do niego przez wpisywanie kolejnych liczb 3, 4, 5, 6, itd

Pracowałem w systemie gdzie wymyślili sobie takie mapowanie id na fakeId. Aplikacja wewnętrzna. Ile było z tym problemu. A i tak staraliśmy się żeby Id było równa FakeId bo wtedy działało peościej

Kolejnym aspektem jest wydajność bazy danych i bazy lepiej sobie radzą z liczbami całkowitymi jako PK a nie losowymi wartościami (UUID), ale to też zależy od silnika. Jedne sobie z tym zagadnieniem radzą lepiej drugie gorzej. Dużo też zależy od ilości danych. Przy małym wolumenie to wpływ na wydajność będzie znikomy, przy milionach rekordów mogą już być kłopoty. Ale znowu dużo zależy od umiejętności bazodanowych i konfiguracji/optymalizacji silnika.

zacząłem się wczytytywać i to kiepski wybór, UUID jest za duży na to, jest problem z wyszukiwaniem po UUID gdy jest PK ze względu na wydajność

Na prawdę z tym UUID jest taki problem? binarnie UUID jest tylko dwókrotnie dłuższy niż Long. Czyli UUID ma 128 bitów a Long w postgresie ma 64 bity. A PostgreSQL ma przecież wsparcie dla UUIDa więc to nie będzie w bazie trzymane jako string tylko jako 128 bitów. Co do losowości to można używać UUIDa opartego na czasie wtedy zawsze jest rosnący. Przynajmniej w Cassandrze to standard, nie wiem jak w PostgreSQL

baza postgres, TSID, GUID nie wchodzą w gre ze wzlędu na brak wsparcia z pudełka

Teraz może wyjdę na lajkonika, ale jaka jest róznica między UUID a GUID? jedno i drugie to 128 bitów. To nie jest tak iż GUID to UUID, ale w M$? Bo oni wszystko musza nazywać po swojemu?

KamilAdam napisał(a):

Pracowałem w systemie gdzie wymyślili sobie takie mapowanie id na fakeId. Aplikacja wewnętrzna. Ile było z tym problemu. A i tak staraliśmy się żeby Id było równa FakeId bo wtedy działało peościej

Klasyk, dlatego nie zalecam tego podejścia.

KamilAdam napisał(a):

Na prawdę z tym UUID jest taki problem? binarnie UUID jest tylko dwókrotnie dłuższy niż Long. Czyli UUID ma 128 bitów a Long w postgresie ma 64 bity. A PostgreSQL ma przecież wsparcie dla UUIDa więc to nie będzie w bazie trzymane jako string tylko jako 128 bitów. Co do losowości to można używać UUIDa opartego na czasie wtedy zawsze jest rosnący.

Są opracowania które pokazują, że UUID jest gorszy wydajnościowo, ja z UUID nie miałem większych problemów, ale to nie znaczy, że inni nie mieli. Dużo zależy od danych, typu aplikacji, itd Jeden przykład tu https://www.cybertec-postgresql.com/en/uuid-serial-or-identity-columns-for-postgresql-auto-generated-primary-keys/

KamilAdam napisał(a):

Na prawdę z tym UUID jest taki problem? binarnie UUID jest tylko dwókrotnie dłuższy niż Long. Czyli UUID ma 128 bitów a Long w postgresie ma 64 bity. A PostgreSQL ma przecież wsparcie dla UUIDa więc to nie będzie w bazie trzymane jako string tylko jako 128 bitów. Co do losowości to można używać UUIDa opartego na czasie wtedy zawsze jest rosnący. Przynajmniej w Cassandrze to standard, nie wiem jak w PostgreSQL

https://vladmihalcea.com/uuid-database-primary-key/ tu oprócz wyjaśnienia dlaczego UUID jest problemem dla PK jest też propozycja dla TSID ale właśnie nie chce korzystać z zewnętrznej biblioteki dla generowania PK

KamilAdam napisał(a):

Teraz może wyjdę na lajkonika, ale jaka jest róznica między UUID a GUID? jedno i drugie to 128 bitów. To nie jest tak iż GUID to UUID, ale w M$? Bo oni wszystko musza nazywać po swojemu?

racja, to chyba twór MS

Można jeszcze robić takie kombinacje jak sqids czyli de facto rosnący INT, ale traktowany funkcją kryptograficzną tak, aby tworzył dość nieprzewidywalne ciągi na froncie.

Jak masz "trochę" tabel, to zrób sobie JEDNEGO sekwencera i podczep go pod wszystkie ID.
Będziesz miał wtedy unikalne ID nie tylko w tabeli, ale również w bazie. i już nie będzie tak łatwo zgadnąć. :)

Marcin.Miga napisał(a):

Jak masz "trochę" tabel, to zrób sobie JEDNEGO sekwencera i podczep go pod wszystkie ID.
Będziesz miał wtedy unikalne ID nie tylko w tabeli, ale również w bazie. i już nie będzie tak łatwo zgadnąć. :)

A to nie obniży wydajności przy duże ilości zapisów?

Jak masz "trochę" tabel, to zrób sobie JEDNEGO sekwencera i podczep go pod wszystkie ID.
Będziesz miał wtedy unikalne ID nie tylko w tabeli, ale również w bazie. i już nie będzie tak łatwo zgadnąć.

@Marcin.Miga - Rozwiniesz temat tego sekwencera - co to jest? Jakiś mechanizm z bazie/gotowa biblioteka, czy sam ma to napisać?
I tak, jak napisał @KamilAdam - nie będzie to miało negatywnego wpływu na wydajność? W końcu jest więcej zamieszania w sprawdzaniu unikalności klucza w X tabelach na bazie niż w jednej - do której aktualnie zapisujesz.

Marcin.Miga napisał(a):

Jak masz "trochę" tabel, to zrób sobie JEDNEGO sekwencera i podczep go pod wszystkie ID.
Będziesz miał wtedy unikalne ID nie tylko w tabeli, ale również w bazie. i już nie będzie tak łatwo zgadnąć. :)

będziesz miał słownik z 10 wartościami też z Id w rodzaju 34524
już nie mówiąc że bezpieczeństwo nie polega na tym że użyszkodnik se nie zgadnie numerka
i jeszcze inna sprawa - masz kilka instancji dla klientów. dodajesz słownik. jakie id maja być dla wartości w tym słowniku? u każdego klienta inne ID?
proszenie się o kłopoty level hard. a co jak trzeba zmergować dwie bazy?

Taki UUID względem zwykłego id inta, będzie tak z O(1) zmieni się na O(log2 n), jeśli po drzewie będzie się wyszukiwać, lub prawie O(1) przy hashmapie, ale po pierwsze, jak będzie się zmieniać ilość danych to ciągle będzie trzeba algorytm hashowania zmieniać w dodatku i tak mogą być kolizje więc najprawdopodobniej będzie po prostu wyszukiwanie binarne w drzewie czyli z jednej operacji mając 1024 danych będziesz robić 10 czyli log2 1024, a normalnie po indexach masz idx * wielkość_elementu (cały wiersz), czyli O(1)
W dodatku UUID to aktualny czas + trochę losowości, to nie jest tak całkiem losowe jak się wydaje, czyli mając index zdradzasz, który ktoś jest, a UUID zdradzasz kiedy ktoś dostał zwrócony dany element czyli czas.

Miang napisał(a):

Marcin.Miga napisał(a):

Jak masz "trochę" tabel, to zrób sobie JEDNEGO sekwencera i podczep go pod wszystkie ID.
Będziesz miał wtedy unikalne ID nie tylko w tabeli, ale również w bazie. i już nie będzie tak łatwo zgadnąć. :)

będziesz miał słownik z 10 wartościami też z Id w rodzaju 34524
już nie mówiąc że bezpieczeństwo nie polega na tym że użyszkodnik se nie zgadnie numerka
i jeszcze inna sprawa - masz kilka instancji dla klientów. dodajesz słownik. jakie id maja być dla wartości w tym słowniku? u każdego klienta inne ID?
proszenie się o kłopoty level hard. a co jak trzeba zmergować dwie bazy?

właśnie w tym rzecz, bezpieczeństwo nie polega na tym, że ktoś numerka nie odgadnie. uuid daje poczucie bezpieczeństwa ale już widziałem przypadki łamiania bo to jest całkowicie losowa wartość. dla mnie kwestie security są bardzo istotne ze względu na charakter podmiotu zamawiającego. tylko co zapewni kwestie security? pk jest też szczegółem bazo danowym, może posiadanie dwóch identyfikatorów jest najlepszym rozwiązaniem? oczywiście można ostatecznie powiązać te identyfikatory ale w security chodzi o to aby jak najbardziej oddalać się od zagrożenia. tylko już przez to przechodziłem i dev expierence jest niski, to oczywiście przeszkadza, trzeba myśleć też nad czy to id czy to drugie. jedno jest istotne przy query inne przy command. tylko faza rozwojowa się kończy i ostatecznie to musi być wszystko uznane za bezpieczne i faktycznie takie być

markone_dev napisał(a):

Problem z wystawianiem PK jako inkrementowany integer na świat jest taki, że łatwo go zgadnąć, co może budzić niepokój bo ktoś może próbować uzyskać dostęp do danych które nie należą do niego przez wpisywanie kolejnych liczb 3, 4, 5, 6, itd

Dlatego warto rozważyć użycie tylko liczb pierwszych.

wooki0342 napisał(a):

właśnie w tym rzecz, bezpieczeństwo nie polega na tym, że ktoś numerka nie odgadnie. uuid daje poczucie bezpieczeństwa ale już widziałem przypadki łamiania bo to jest całkowicie losowa wartość. dla mnie kwestie security są bardzo istotne ze względu na charakter podmiotu zamawiającego. tylko co zapewni kwestie security? pk jest też szczegółem bazo danowym, może posiadanie dwóch identyfikatorów jest najlepszym rozwiązaniem? oczywiście można ostatecznie powiązać te identyfikatory ale w security chodzi o to aby jak najbardziej oddalać się od zagrożenia. tylko już przez to przechodziłem i dev expierence jest niski, to oczywiście przeszkadza, trzeba myśleć też nad czy to id czy to drugie. jedno jest istotne przy query inne przy command. tylko faza rozwojowa się kończy i ostatecznie to musi być wszystko uznane za bezpieczne i faktycznie takie być

Ale jakiej konkretnie odpowiedzi oczekujesz? Że ktoś ci doradzi idź w rozwiązanie A albo idź w rozwiązanie B? Dostałeś odpowiedzi pokazujące za i przeciw każdego rozwiązania. Teraz twoim zadaniem jako programisty architekta akrobaty jest spojrzeć na wymagania pod kątem security i dobrać rozwiązanie analizując wszystkie za i przeciw. Tu nie ma jednej poprawnej odpowiedzi. To co się sprawdzi w jednym typie aplikacji nie sprawdzi się w drugim.

Nie mam oczekiwań. pomyślałem, że warto tutaj zadać to pytanie i poznać inny punkt widzenia na te sprawę. Twoim zdaniem nie powinienem już ciągnąć dalej rozmowy tylko zakończyć na pierwszym poście?

cerrato napisał(a):

Jak masz "trochę" tabel, to zrób sobie JEDNEGO sekwencera i podczep go pod wszystkie ID.
Będziesz miał wtedy unikalne ID nie tylko w tabeli, ale również w bazie. i już nie będzie tak łatwo zgadnąć.

@Marcin.Miga - Rozwiniesz temat tego sekwencera - co to jest? Jakiś mechanizm z bazie/gotowa biblioteka, czy sam ma to napisać?
I tak, jak napisał @KamilAdam - nie będzie to miało negatywnego wpływu na wydajność? W końcu jest więcej zamieszania w sprawdzaniu unikalności klucza w X tabelach na bazie niż w jednej - do której aktualnie zapisujesz.

To wbudowany mechanizm w PostgreSQL. Domyślnie "bigserial" jest zamieniany na "bigint" + "default nexval()".
A tu przykład jak to zaimplementować i jak to działa:
https://www.db-fiddle.com/f/aNoPgGTAYGnQLSWN6i8Pmx/0

@Marcin.Miga dzięki, fajne to, nie znałem tego mechanizmu

Tylko odnośnie tego fragmentu - unikalne ID nie tylko w tabeli, ale również w bazie. i już nie będzie tak łatwo zgadnąć. - tutaj nadal można zgadywać. Wprawdzie nie masz ciągłości, więc nie możesz założyć, że po 1779 będzie 1780, ale jak chwilę postrzelasz to dojdziesz, że już 1846 jest pasujące. Może trochę to utrudnić życie radzieckiego hackera, ale (w mojej ocenie) - wiele nie zmienia to w zakresie bezpieczeństwa. Myślałem, że te sekwencery mają bardziej rozbudowane opcje - tworzą coś w stylu UUID itp.- i stąd moje wątpliwości odnośnie wydajności takiego rozwiązania.

to że hejtuje takie rozwiązanie jak jedna sekwencja do kilku tabel to akurat ze smutnego doświadczenia. genialny pomysł sławetnego dyrektorka

wooki0342 napisał(a):

Nie mam oczekiwań. pomyślałem, że warto tutaj zadać to pytanie i poznać inny punkt widzenia na te sprawę. Twoim zdaniem nie powinienem już ciągnąć dalej rozmowy tylko zakończyć na pierwszym poście?

Nie. Chodziło mi o to, że nie dostaniesz jednoznacznej odpowiedzi czy zrobić tak czy siak.

Ja dodam jedną nieoczywistą zaletę stosowania UUID , której co prawda przy projektowaniu systemu nie powinno się brać pod uwagę jako zalety, ale może się okazać pomocna po paru latach (team utrzymanie)... W skrócie - przychodząc do słabo udokumentowanego projektu, w którym nie wszystkie relacje zostały zdefiniowane w strukturze bazy ( brak części FK, słabe powiązania), można , korzystając z "unikalności" UUID, w miarę w szybkim tempie odkryć wszystkie "niejawne" relacje, W teorii jest to obejście projektowej "patologii', ale w praktyce pozwala znacząco przyspieszyć pewne utrzymaniowe "procesy śledcze"

Jeśli UUIDy wciąż są unikatowe, to szambo nie jest jeszcze wystarczająco głębokie.

Może nie ta baza, ale wpis chyba w temacie:

Pod linkiem film na jutubie: