Идентификатор пользователя Facebook поднимается до 2 ^ 32, который, по моему мнению, 4294967296.
mySQL unsigned int range - от 0 до 4294967295 (это 1 короткий или моя математика неверна) и его неподписанный большой диапазон int от 0 до 18446744073709551615
int = 4 байта, bigint = 8 байт
ИЛИ
Сохранять ли я его как строку?
varchar (10) =? байты
Как это будет эффективно, я слышал, что номера дескрипторов mysql намного лучше, чем строки (производительность - мудрый). Итак, что вы, ребята, рекомендуете
Поскольку Facebook назначает идентификаторы, а не вы, вы должны использовать BIGINT.
Facebook не назначает идентификаторы последовательно, и я подозреваю, что у них есть некоторый режим для присвоения номеров.
Недавно я исправил именно эту ошибку, так что это настоящая проблема.
Я бы сделал UNNIGNED просто потому, что это то, что есть.
Я бы не использовал строку. Это делает сравнение болезненным, а ваши индексы неуклюже, чем они должны быть.
Вы больше не можете использовать INT. Вчера вечером у меня было два идентификатора пользователя, которые превысили INT (10).
Я использую 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 = ?
таблица профилей почти всегда запрашивается практически для любого запроса, поэтому я не считаю это дополнительным шагом.
И, конечно, также довольно легко кэшировать первый запрос для некоторой дополнительной производительности.
Если вы читаете это в 2015 году, когда facebook обновил свою версию API до версии 2.0. Они добавили в свою документацию записку о том, что их идентификаторы будут изменены и будут обладать приложением. Так что, возможно, в будущем появится большая вероятность, что они могут изменить все идентификаторы на цифру Alpha.
https://developers.facebook.com/docs/apps/upgrading#upgrading_v2_0_user_ids Поэтому я бы предложил сохранить тип в varchar и избежать любых будущих миграционных болей.
Ваша математика немного неправильна... помните, что наибольшее количество, которое вы можете сохранить в N байтах, равно 2 ^ (N) - 1... не 2 ^ (N). Есть 2 ^ N возможных номеров, однако наибольшее количество, которое вы можете сохранить, на 1 меньше.
Если Facebook использует неподписанный большой int, вы должны это использовать. Вероятно, они не назначают их последовательно.
Да, вы могли бы уйти с varchar... однако это было бы медленнее (но, вероятно, не так сильно, как вы думаете).
Сохраните их как строки.
API-интерфейс Facebook возвращает идентификаторы как строки, поэтому, если вы хотите, чтобы сравнения работали без использования, вы должны использовать строки. ИМО это превосходит другие соображения.
Я бы просто придерживался INT. Это легко, оно мало, оно работает, и вы всегда можете изменить колонку на больший размер в будущем, если вам нужно.
FYI:
VARCHAR(n) ==> variable, up to n + 1 bytes CHAR(n) ==> fixed, n bytes
Если вы не ожидаете, что более 60% населения мира будет зарегистрировано, int должен делать?