Facebook id_użytkownika: big_int, int lub string?

Question

Facebooka użytkowniku ID idziemy do 2^32 .. który według moich obliczeń to zakres 4294967296.

MySQL unsigned int jest 0 do 4294967295 (co 1 krótki - czy moja matematyka jest źle) i jej niepodpisane duże INT Zakres wynosi od 0 do 18446744073709551615

int = 4 bajty, bigint = 8 bajtów

LUB

Czy muszę przechowywać go jako ciąg?

varchar (10) =? bajty

W jaki sposób wpłynie to na wydajność, słyszałem, że liczba uchwytów mysql jest o wiele lepsza niż łańcuchy (pod względem wydajności). Więc co polecacie?

Answer 1

Ponieważ Facebook przypisuje identyfikatory, a nie ty, koniecznością użytku BIGINTs.

Facebook nie przypisuje identyfikatorów sekwencyjnie i podejrzewam, że mają one pewien system przydzielania numerów.

Niedawno naprawiłem dokładnie ten błąd, więc jest to poważny problem.

Uczyniłbym to ZAKAZANYM, po prostu dlatego, że tak właśnie jest.

Chciałbym nie użyć ciąg. To sprawia, że ​​porównania są bolesne, a indeksy są bardziej kruche, niż powinny.

Answer 2

O ile nie spodziewacie się, że więcej niż 60% światowej populacji zarejestruje się, int powinno zrobić?

Answer 3

Po prostu trzymałbym się z INT. To proste, jest małe, działa i zawsze możesz w razie potrzeby zmienić kolumnę na większy rozmiar w przyszłości.

FYI:

VARCHAR(n) ==> variable, up to n + 1 bytes
CHAR(n) ==> fixed, n bytes

Answer 4

Twoja matematyka jest trochę zła ... pamiętaj, że największą liczbą, jaką możesz zapisać w N bajtach, jest 2^(N) - 1 ... nie 2^(N). Istnieją 2^N możliwe numery, jednak największą liczbą, jaką można zapisać, jest 1 mniej.

Jeśli Facebook używa niepodpisanego dużego int, powinieneś go użyć. Prawdopodobnie nie przypisują ich kolejno.

Tak, możesz uciec z varcharem ... jednak byłoby wolniej (ale prawdopodobnie nie tak bardzo, jak myślisz).

Answer 5

Nie możesz już używać INT. Zeszłej nocy miałem dwa identyfikatory użytkowników, które maksymalizowały INT (10).

Answer 6

Używam biginta do przechowywania identyfikatora na Facebooku, ponieważ tak właśnie jest.

ale wewnętrznie dla kluczy podstawowych i obcych tabel, używam smallint, ponieważ jest mniejszy. Ale także dlatego, że jeśli bigint powinien kiedykolwiek stać się ciągiem znaków (aby znaleźć użytkowników według nazwy użytkownika zamiast id), mogę łatwo to zmienić.

więc mam tabelę, która wygląda tak:

profile 
- profile_key smallint primary key 
- profile_name varchar 
- fb_profile_id bigint 

i jeden, który wygląda tak

something_else 
- profile_key smallint primary key 
- something_else_key smallint primary key 
- something_else_name varchar 

i moich zapytań dla strony przypalić może być coś takiego:

select profile_key, profile_name 
from profile 
where fb_profile_id = ? 

teraz biorę klucz_profilu i używam go w następnym zapytaniu

select something_else_key, something_else_name 
from something_else 
where profile_key = ? 

Tabela profili prawie zawsze jest pytana o prawie każde żądanie, więc nie uważam tego za dodatkowy krok.

Oczywiście łatwo jest zapisać w pamięci podręcznej pierwsze zapytanie o dodatkową wydajność.

Answer 7

Przechowuj je jako struny.

Interfejs API wykresu Facebook zwraca identyfikatory ids jako łańcuchy, więc jeśli chcesz, aby porównania działały bez konieczności przesyłania, użyj łańcuchów. IMO to trumpuje inne względy.

Answer 8

Jeśli czytasz to w 2015 roku, kiedy Facebook zaktualizował wersję API do wersji 2.0. Dodali notatkę do swojej dokumentacji stwierdzającą, że ich identyfikatory zostaną zmienione i będą miały zasięg aplikacji. Być może w przyszłości będzie ogromna możliwość, że mogą zmienić wszystkie identyfikatory na alfanumeryczne.

https://developers.facebook.com/docs/apps/upgrading#upgrading_v2_0_user_ids Więc proponuję zachować typ do varchar i uniknąć przyszłych bóle migracji