Identifiant utilisateur Facebook: big_int, int ou string?

Question

Facebook de l'utilisateur, id aller jusqu'à 2^32 .. qui selon mes calculs, il 4294967296.

mySQL unsigned int de la plage est de 0 à 4294967295 (qui est 1 à court ou mon calcul est faux) et son unsigned grand int de la plage est de 0 à 18446744073709551615

int = 4 octets, bigint = 8 octets

OU

Dois-je le conserver comme une chaîne de caractères?

varchar(10) = ? octets

Comment sera-ce l'effet de l'efficacité, j'ai entendu dire que mysql poignée de numéros de loin mieux que des chaînes de caractères (performance sage). Alors, que faites-vous les gars recommander

Answer 1

Comme Facebook attribue les identifiants, et non vous, vous devez utiliser des BIGINT.

Facebook n'attribue pas les identifiants de manière séquentielle, et je suppose qu'ils disposent d'un régime d'attribution de numéros.

J'ai récemment corrigé exactement ce bogue, donc c'est un vrai problème.

Je le ferais sans signature, simplement parce que c'est ce que c'est.

Je ne voudrais pas utiliser une chaîne. Cela rend les comparaisons douloureuses et vos index plus encombrants qu'ils ne le devraient.

Answer 2

Vous ne pouvez plus utiliser INT. La nuit dernière, j'ai eu deux identifiants d'utilisateur qui ont dépassé INT (10).

Answer 3

J'utilise un bigint pour stocker le facebook id, parce que c'est ce qu'il est.

mais, en interne, pour les primaires et les clés étrangères des tables, j'utilise un smallint, car il est plus petit. Mais aussi parce que si le type bigint ne devrait jamais avoir à devenir une chaîne de caractères (pour trouver des utilisateurs par nom d'utilisateur au lieu de l'id), je peux facilement changer.

donc j'ai une table qui ressemble à ceci:

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

et celui qui ressemble à ceci

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

et mes requêtes pour un singe page pourrait être quelque chose comme ceci:

select profile_key, profile_name
from profile
where fb_profile_id = ?

maintenant, je prends le profile_key et de l'utiliser dans la requête suivante

select something_else_key, something_else_name
from something_else
where profile_key = ?

la table de profil presque toujours interrogé pour presque toutes les demandes de toute façon, je ne considère pas cela une étape supplémentaire.

Et bien sûr, il est également très à l'aise pour mettre en cache la première requête pour un peu de performance.

Answer 4

Votre calcul est un peu faux ... rappelez-vous que le plus grand nombre que vous pouvez stocker en N octets est 2 ^ (N) - 1 ... pas 2 ^ (N). Il y a 2 ^ N nombres possibles , mais le plus grand nombre que vous pouvez enregistrer est égal à 1 moins.

Si Facebook utilise un big int non signé, vous devriez l'utiliser. Ils ne les attribuent probablement pas séquentiellement.

Oui, vous pourriez vous en tirer avec un varchar ... mais ce serait plus lent (mais probablement pas autant que vous le pensez).

Answer 5

Rangez-les sous forme de chaînes.

L'API Graph Facebook renvoie les identifiants sous forme de chaînes. Par conséquent, si vous souhaitez que les comparaisons fonctionnent sans avoir à effectuer de transtypage, vous devez utiliser des chaînes. OMI cela l'emporte sur d'autres considérations.