Tworze system, który komunikuje się z jakimś tam klientem tworzonym przez inny zespół w innej technologii i od nich dostaje obiekty, które ID mają long? a nie string.
Co o tym myślicie?
Czemu po swojej stronie miałbym trzymać też long? zamiast string?
Serio? oO Bo na przykład long to idealny kandydat na autoinkrementujący się klucz sztuczny w bazie danych?
Nie, typ danych dopasowuje się do potrzeb, a nie do pomysłów wykładowcy.
Id powinno być liczbą, bo porównywanie liczb jest znacznie szybsze niż stringów. A Id porównuje się często, we wszystkich operacjach typu wyszukiwanie, złączenia, przeliczanie indeksów przy wstawianie danych, itd. Jeśli danych jest tyle, że long to za mało, to używa się Guida, a nie stringa.
Stringa używa się do danych tekstowych. Szczególnym ich przypadkiem są numery. Numery to nie liczby, nawet jeśli składają się z samych cyfr jak PESEL czy IBAN.
@Chory Szewc totalnie idiotyczny pomysł, co więcej może potem powodować wiele problemów, bo indeksy na stringach są nieporównywalnie wolniejsze od indeksów na liczbach.
bartk napisał(a):
Jedyne zastosowanie ID z typem string jakie przychodzi mi do glowy, to gdy planujemy po cichu sabotazowac dany system. :-)
--somekind napisał(a):
Ale rozumiesz, że to oni mają dobrze, a Ty jakieś WTF odstawiasz?
Przestań psuć i zacznij też używać sensownych typów do Id, string to najgorszy możliwy wybór.
--Shalom napisał(a):
@Chory Szewc totalnie idiotyczny pomysł, co więcej może potem powodować wiele problemów, bo indeksy na stringach są nieporównywalnie wolniejsze od indeksów na liczbach.
--
Niekoniecznie.
https://www.depesz.com/2012/06/07/123-vs-depesz-what-is-faster/
Jeżeli String jest stosunkowo krótki, to różnica pomiędzy PK na String, a PK na na przykład Long nie przekracza 5%.
ID typu string to np. UUID, który stosowany jest przy klastrowaniu, oznaczaniu partycji w Linuxie a PostgreSQL posiada już nawet taki typ jak UUID https://www.postgresql.org/docs/9.1/static/datatype-uuid.html
Nawet jakby do tego zastosować wyszukiwanie metodą dziel i rządź, to wyszło by tyle samo operacji co na intach, ale mniej kombinacji ze względu na nie printowalne znaki.
I jakby ktoś wstrzyknął liczbę z poza zakresu, to po prostu wybrany by był string, nieskorelowany z nim z powodu aproksymacji.
Ale naprawa tego wymagała by jedynie upewnienia się, że znaleziony string jest, tym jakiego szukano czyli + jeden if do operacji np. 32 stringi 5 sprawdzeń głębokości + 1 weryfikacyjny.
No ale dokladnie jak @karolinaa pisze. Czasem UUID jest całkiem rozsądnym rozwiązaniem i wtedy można go wrzucić jak varchar(16); (plus jeszcze prawie każda baza ma tricki / własne typy na uuidy , guidy)
Tak jak niektórzy przedmówcy powiedzieli identyfikator powinien być liczbą z powodów optymalizacji porównań, wyszukiwań, indexów, etc.!
Jedyne argumenty przemawiające za użyciem stringa (jedynie w postaci UUID/GUID) to:
-> środowisko rozproszone
-> duża liczba rekordów (większa od zakresu int/long)
-> unikalność identyfikatorów niezależnie od typu
Ale GUID to jest przecież liczba, a nie żaden string. :|T
A to, że wyświetlamy go sobie jako string jest tylko dla ludzkiej wygodny. Przecież inty i longi też widzimy jako string.
Wszystko właściwie zostało już powiedziane. GUID to LICZBA, a nie string. Identyfikatory nie powinny być stringiem. Mogą nim być technicznie, ale nie powinni. Czy możesz dać w mordę wykładowcy? Technicznie możesz. Ale raczej nie powinieneś.
Stringów używa się tylko i wyłącznie tam, gdzie potrzebujemy stringa. Czyli teksty i długie numery (PESEL, IBAN - jak mówił somekind).
C# 
