Unikalne numereyczne Id dla stringa

Potrzebuje wyliczyc unikalne numeryczne id dla stringa. Chodzi mi o to ze mam w bazie zapisywane jakis tekst. Ale przy kolejnych iteracjach wpisywania chce wykryc ze dany text juz jest w bazie i go pominac zeby uniknac duplikatu. Numeryczna wartosc trzymalbym w osobnej kolumnie obok textu np text_crc i po niej szukal tych samych textow.

Zalezy mi na wartosci numerycznej bo porownania na numerykach czy to w bazie sql czy javie sa szybsze niz robienie select z warunkiem porownania stringow

Na poczatku myslalem o wyliczeniu crc ale w javie crc bazuje tylko na 32 bitach wiec ryzyoko wyliczenia tego samego crc dla roznych tekstow jest dosc wysokie.

Ma ktos jakis pomysl jak to zrobic z jak najmniejszym ryzykiem wyliczenia tego samego id?

Hm, tylko że jak trzymasz te stringi w bazie to prawdopodobnie i tak najlepiej będzie zrzucić sprawdzanie na bazę bo żeby sprawdzić po stronie javy to musisz pobrać wszystkie stringi.
Jak zrzucisz to na postgresa to masz INSERT ... ON CONFLICT DO NOTHING/UPDATE ("UPSERT") a potem select. No chyba że INSERT ON CONFLICT uda się jeszcze połączyć z INSERT RETURNING i masz jedną operację bazodanową po indeksie

Jak bardzo chcesz zrobić to w Javie można użyć jakąś funkcję haszującą. https://en.wikipedia.org/wiki/SHA-2 i https://en.wikipedia.org/wiki/SHA-3 to liczby 512 bitowe, może jest coś dłuższego. No ale konfliktów raczej nie unikniesz

BTW jak wrzucasz stringi do hashmapy jako klucz to najpierw jest porównywany hashcode (32 bitowy), a dopiero potem jest używany equals. W zasadzie to tak jest dla wszystkich obiektow

zapomnialem dodac ze liczac numeryczna wartosc dla stringa tez bym ja przechowywal z rekorem tekstu w osobnej kolumni np text_crc i po niej szukal tych samych textow.

Słuchaj kolegów jak ci dobrze radzą. Unikalny indeks na odpowiednim polu/ścieżce w bazie danych będzie o rzędy wielkości szybszy niż jakakolwiek atrapa, którą stworzysz. Czego byś nie użył, to transformacja ciągu znaków o nieograniczonej długości do liczby całkowitej o stałym rozmiarze zawsze ma w sobie ryzyko wystąpienia konfliktów. Jeżeli wykorzystasz jakąś funkcję skrótu, to to ryzyko może spaść do niskiej wartości, ale jednocześnie spadnie też hipotetyczny zysk na wydajności.

maniek41 napisał(a):

Zalezy mi na wartosci numerycznej bo porownania na numerykach czy to w bazie sql są szybsze

Urban legend. Tak / nie / zależy. Nie ośmieliłbym się postawić takiej tezy bez badań

A na pewno dorzucasz 100x wiecej buchalterii aby zrealizować ten pomysł na niepotwierdzoną oszczędność nanosekund ... ops... wyliczenie CRC, szukanie po alternatywnych kolumnach .... co jeszcze ...
Pomyliłem się, proponujesz narzut nie 100x ale 10000x większy niż zwykłe porównanie stringa

Antyoptymalizacja

KamilAdam napisał(a):

Hm, tylko że jak trzymasz te stringi w bazie

Jak w bazie

@maniek41:

Co to za dane, ile ich jest, jak czas gromadzenia?
Jak będzie przetwarzana?

W podtekście: czy w ogóle jakakowliek baza, czy kontener w RAM.
A jak(?) baza, i szukamy naosekund, to nie SQL a key-value

edit: https://www.google.com/search?client=firefox-b-d&q=java+key+value+persitence+dictionary
W tym (nie znałem, pewnie użyję niedługo) https://swaydb.io/?language=java czy http://rocksdb.org/

Baza to postgresql. Szacowana wielkosc conajmniej kilkadziesiat milionow wpisow.

Prawdoodoobnie pomysl KamilAdama jest najoptymalniejszy wiec mozliwe ze w ta strone pojde.

Nie rozumiem trochę:
masz bazę relacyjną, masz tabelę w której jedna z kolumn zawiera ciąg znaków i nie chcesz aby ciąg znaków w tej kolumnie się powtórzył.
Czemu zwyczajnie nie ustawisz odpowiedniego constraint'a na kolumnie i nie obsłużysz odpowiedniego wyjątku przy zapisie?

Jakie ręczne wyliczanie crc? Byłem w projekcie gdzie ktoś wpadł na genialny pomysł opracowania własnego algorytmu po czym okazało się, że ryzyko duplikatów przy sporym ruchu było duże.

RequiredNickname napisał(a):

Jakie ręczne wyliczanie crc? Byłem w projekcie gdzie ktoś wpadł na genialny pomysł opracowania własnego algorytmu po czym okazało się, że ryzyko duplikatów przy sporym ruchu było duże.

Pewien rodzaj specjalistów WIE NIEZŁOMNIE, że kolo przez niego wynalezione będzie bardziej okrągłe od tego, które podobno wynalezli ci z krzywymi nosami za górami.
Fakty nie maja znaczenia

maniek41 napisał(a):

Baza to postgresql. Szacowana wielkosc conajmniej kilkadziesiat milionow wpisow.

ZrobieDobrze napisał(a):

Jak będzie przetwarzana?

Nie odpowiedziałeś