Facebook user_id : big_int, int 또는 문자열?

Facebook user_id : big_int, int 또는 문자열?

페이스북 사용자 ID가 2^32까지 올라갑니다.제가 계산하면 4294967296입니다.

mySQL의 서명되지 않은 int의 범위는 0 ~ 4294967295(1이 짧거나 내 수학이 틀림)이고 서명되지 않은 big int의 범위는 0 ~ 18446744073709551615입니다.

int = 4바이트, bigint = 8바이트

오어

끈으로 보관하면 되나요?

varchar(10) = ?바이트

효율성에 어떤 영향을 미칠까요, mysql 핸들의 숫자가 문자열보다 훨씬 더 좋다고 들었습니다(퍼포먼스 와이즈).그래서 여러분들이 추천하는 것은.

페이스북은 사용자가 아닌 ID를 할당하기 때문에 BIGINT를 사용해야 합니다.

페이스북은 ID를 순차적으로 할당하지 않으며, 번호를 할당할 수 있는 체제를 가지고 있다고 생각합니다.

저는 최근에 이 버그를 정확히 고쳤기 때문에 정말 문제입니다.

저는 단순히 그것이 그것이기 때문에 그것을 서명하지 않은 것으로 만들 것입니다.

저는 끈을 사용하지 않습니다.이로 인해 비교가 어려워지고 인덱스가 필요 이상으로 엉성해집니다.

INT는 더 이상 사용할 수 없습니다.어젯밤에 INT(10)를 최대치로 잡은 사용자 ID가 두 개 있었습니다.

나는 페이스북 아이디를 저장할 때 빅인트를 사용합니다. 왜냐하면 그것이 바로 그것이기 때문입니다.

하지만 내부적으로 테이블의 주요 키와 외국 키에 대해서는 작은 int를 사용합니다. 왜냐하면 그것은 더 작기 때문입니다.하지만 또한 bigint가 문자열이 되어야 한다면(id 대신 사용자 이름으로 사용자를 찾기 위해) 쉽게 변경할 수 있기 때문입니다.

그래서 나는 이렇게 생긴 테이블을 가지고 있습니다.

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

이렇게 생긴 것도

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

한 페이지에 대한 제 질문은 다음과 같습니다.

select profile_key, profile_name
from profile
where fb_profile_id = ?

이제 profile_key를 가져가서 다음 쿼리에 사용합니다.

select something_else_key, something_else_name
from something_else
where profile_key = ?

어쨌든 프로필 테이블은 거의 항상 거의 모든 요청에 대해 조회되기 때문에 추가적인 단계라고 생각하지 않습니다.

또한 추가 성능을 위해 첫 번째 쿼리를 캐싱하는 것도 매우 쉽습니다.

페이스북이 API를 2.0 버전으로 업그레이드한 2015년에 이 글을 읽고 있다면요.그들은 문서에 ID가 변경되고 앱 범위를 가질 것이라는 내용의 메모를 추가했습니다.따라서 나중에 모든 ID를 알파 숫자로 변경할 가능성이 클 수도 있습니다.

https://developers.facebook.com/docs/apps/upgrading#upgrading_v2_0_user_ids 따라서 저는 varchar로 유형을 유지하고 향후 마이그레이션 문제를 피할 것을 제안합니다.

당신의 수학은 조금 틀렸습니다...N바이트로 저장할 수 있는 최대 개수는 2^(N) - 1...임을 기억하십시오.2^(N)이 아닙니다.가능한 숫자는 2^N개가 있지만, 저장할 수 있는 가장 큰 숫자는 그보다 1개 적은 숫자입니다.

만약 페이스북이 서명되지 않은 빅 인트를 사용한다면, 당신은 그것을 사용해야 합니다.그들은 아마 순차적으로 배정하지 않을 겁니다.

네, 바카르로 도망칠 수도 있고요그러나 그것은 더 느릴 것입니다(그러나 아마도 당신이 생각하는 것만큼은 아닐 것입니다).

끈으로 보관합니다.

Facebook Graph API는 ids를 문자열로 반환하기 때문에, 비교가 캐스트할 필요 없이 작동하려면 문자열을 사용해야 합니다.IMO 이것은 다른 고려사항들을 능가합니다.

그냥 INT로 하겠습니다.쉽고, 작고, 효과가 있으며, 나중에 필요할 경우 언제든지 열을 더 큰 크기로 변경할 수 있습니다.

참고:

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

전 세계 인구의 60% 이상이 가입할 것으로 예상하지 않는 한, 가입해야 합니까?

언급URL : https://stackoverflow.com/questions/2172126/facebook-user-id-big-int-int-or-string