Facebook user_id: big_int, int или string?

Идентификатор пользователя Facebook поднимается до 2 ^ 32, который, по моему мнению, 4294967296.

mySQL unsigned int range - от 0 до 4294967295 (это 1 короткий или моя математика неверна) и его неподписанный большой диапазон int от 0 до 18446744073709551615

int = 4 байта, bigint = 8 байт

ИЛИ

Сохранять ли я его как строку?

varchar (10) =? байты

Как это будет эффективно, я слышал, что номера дескрипторов mysql намного лучше, чем строки (производительность - мудрый). Итак, что вы, ребята, рекомендуете

Ответ 1

Поскольку Facebook назначает идентификаторы, а не вы, вы должны использовать BIGINT.

Facebook не назначает идентификаторы последовательно, и я подозреваю, что у них есть некоторый режим для присвоения номеров.

Недавно я исправил именно эту ошибку, так что это настоящая проблема.

Я бы сделал UNNIGNED просто потому, что это то, что есть.

Я бы не использовал строку. Это делает сравнение болезненным, а ваши индексы неуклюже, чем они должны быть.

Ответ 2

Вы больше не можете использовать INT. Вчера вечером у меня было два идентификатора пользователя, которые превысили INT (10).

Ответ 3

Я использую bigint для хранения идентификатора facebook, потому что это то, что оно есть.

но внутренне для первичных и внешних ключей таблиц, я использую smallint, потому что он меньше. Но также потому, что если 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 = ?

таблица профилей почти всегда запрашивается практически для любого запроса, поэтому я не считаю это дополнительным шагом.

И, конечно, также довольно легко кэшировать первый запрос для некоторой дополнительной производительности.

Ответ 4

Если вы читаете это в 2015 году, когда facebook обновил свою версию API до версии 2.0. Они добавили в свою документацию записку о том, что их идентификаторы будут изменены и будут обладать приложением. Так что, возможно, в будущем появится большая вероятность, что они могут изменить все идентификаторы на цифру Alpha.

https://developers.facebook.com/docs/apps/upgrading#upgrading_v2_0_user_ids Поэтому я бы предложил сохранить тип в varchar и избежать любых будущих миграционных болей.

Ответ 5

Ваша математика немного неправильна... помните, что наибольшее количество, которое вы можете сохранить в N байтах, равно 2 ^ (N) - 1... не 2 ^ (N). Есть 2 ^ N возможных номеров, однако наибольшее количество, которое вы можете сохранить, на 1 меньше.

Если Facebook использует неподписанный большой int, вы должны это использовать. Вероятно, они не назначают их последовательно.

Да, вы могли бы уйти с varchar... однако это было бы медленнее (но, вероятно, не так сильно, как вы думаете).

Ответ 6

Сохраните их как строки.

API-интерфейс Facebook возвращает идентификаторы как строки, поэтому, если вы хотите, чтобы сравнения работали без использования, вы должны использовать строки. ИМО это превосходит другие соображения.

Ответ 7

Я бы просто придерживался INT. Это легко, оно мало, оно работает, и вы всегда можете изменить колонку на больший размер в будущем, если вам нужно.

FYI:

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

Ответ 8

Если вы не ожидаете, что более 60% населения мира будет зарегистрировано, int должен делать?