Facebook user_id: big_int, int или string?

Question

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

Диапазон беззнакового целочисленного значения в MySQL - от 0 до 4294967295 (это 1 короткий или моя математика неверна) и диапазон его беззнакового большого целого от 0 до 18446744073709551615

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

OR

Хранить ли это как строку?

varchar (10) =? байт

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Answer 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_ и использую его в следующем запросе

select something_else_key, something_else_name
from something_else
where profile_key = ?

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

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

Answer 4

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

Answer 5

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

Если Facebook использует unsigned big int, то вы должны использовать это. Они, вероятно, не назначают их последовательно.

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

Answer 6

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

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

Answer 7

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

FYI:

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

Answer 8

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