2
Je travaille sur une base de données qui utilise des entiers comme clés primaires pour un certain nombre de tables. Je voudrais rendre les clés primaires relativement difficiles à deviner - elles n'ont pas besoin d'être super-serrées, mais d'incrémenter des entiers dans les centaines inférieures. Puisque je suis en train de rééquiper ceci en schémas existants, avec des données existantes, il n'est pas possible de changer le type de données de la clé primaire (integer). Ce que je me demande, c'est comment générer les ID. Jusqu'à présent, je peux penser à ces options:Clés primaires entières non indispensables pour MySQL
- Générez des UUID en utilisant
UUID()et convertissez-les en nombre entier. - Conservez une table distincte complète d'entiers aléatoires et utilisez une procédure pour sélectionner et supprimer un de la table dans une transaction.
- Utilisez l'horodatage UNIX, plus un nombre aléatoire à n chiffres, par ex.
CONCAT(UNIX_TIMESTAMP(),SUBSTRING(RAND() FROM 3 FOR 6))
Je suis ouvert à d'autres suggestions, aussi.
J'apprécierais toutes les pensées que vous pouvez offrir.
Merci, Ross
Pourquoi avez-vous besoin de cela? Votre application n'applique-t-elle pas une plus grande sécurité que de se fier à des personnes ne devinant pas des ID valides? –
connexes: les guids sont souvent partiellement séquentiels pour permettre les meilleures performances ('newsequentialid()' sur SQL 2005+), permettent l'utilisation d'index clusterisés et la réplication de base de données, IIRC. Voir, par exemple. http://www.codinghorror.com/blog/2007/03/primary-keys-ids-versus-guids.html – sehe
@MartinSmith: ce type de fuite d'informations est plus souvent un problème de confidentialité que de sécurité. Mais les informations divulguées pourraient être utilisées pour un avantage stratégique (par exemple, savoir exactement combien d'articles une boutique en ligne a vendus aujourd'hui, ou combien de plaintes ont été déposées auprès d'une entreprise, etc.) – sehe