Quel type d'ID utiliser et comment le stocker dans la base de données?

Question

Je travaille actuellement sur un nouveau projet web avec différents types d'entités. Ce service sera accessible via une API REST, et je pense à extrémités comme:

api.example.com/users/{user_id}

Pour cela, je pense qu'un ID automatique supplémentaire pour les utilisateurs sera une mauvaise approche, puisque tout le monde peut hit: api.example.com/users/1, puis api.example.com/users/2, api.example.com/users/3, et ainsi de suite.

Maintenant, je pense à utiliser UUID, mais je ne sais pas si c'est une bonne idée, parce que c'est un VARCHAR(36). Pour ces raisons, je fais quelque chose comme ça quand je produis l'ID utilisateur sur la INSERT requête (j'utilise MySQL):

unhex(replace(uuid(),'-',''))

Avec cela, je le casting UUID binaire. Et je stocke un BINARY(16) sur la base de données à la place.

Et quand je veux récupérer les informations de base de données, je peux utiliser quelque chose comme ça:

SELECT hex(id), name FROM user;

et

SELECT hex(id), name FROM user WHERE hex(id) = '36c5f55620ef11e7b94d6c626d968e15';

Alors, je travaille avec la forme hexadécimaux, mais en le stockant sous forme binaire.
C'est une bonne approche?

Answer 1

Presque là ...

index sont votre ami de performance. On peut supposer que id est indexée, puis

WHERE id = function('...') 

utilise l'index et va droit à la ligne, mais

WHERE function(id) = '...' 

ne peut pas utiliser l'index; à la place, il balaie toutes les lignes, vérifiant chacune d'entre elles. Pour une grande table, c'est sloooow.

Alors ...

Utilisez cette option pour stocker:

INSERT INTO tbl (uuid, ...) 
    VALUES 
    (UNHEX(REPLACE(UUID(), '-', '')), ...); 

Et ceci pour tester le:

SELECT ... WHERE 
    uuid = UNHEX(REPLACE('786f3c2a-21f6-11e7-9392-80fa5b3669ce', '-', '')); 

Si vous choisissez d'envoyer (via REST) ​​32 caractères sans les tirets, vous pouvez comprendre cette variation mineure.

Comme cela devient fastidieux, créez une paire de fonctions stockées. Oh, j'en ai un pour toi; voir http://mysql.rjweb.org/doc.php/uuid. Cela explique également pourquoi les UUID sont inefficaces pour les tables énormes, et un moyen de contourner cela.