Votre idée de hacher de longues chaînes pour créer un jeton sur lequel effectuer une recherche dans un magasin (cache ou base de données) est bonne. J'ai vu cela se faire pour des chaînes extrêmement grandes et dans des environnements à volume élevé, et cela fonctionne très bien.
"Quel hachage utiliseriez-vous pour cette application ?"
- Je ne pense pas que l'algorithme de chiffrement (hachage) soit vraiment important, car vous ne hachez pas pour chiffrer les données, vous hachez pour créer un jeton sur lequel utiliser comme clé pour rechercher des valeurs plus longues. Le choix de l'algorithme de hachage doit donc être basé sur la vitesse.
"Voulez-vous calculer le hachage dans le code ou laisser la base de données le gérer ?"
- Si c'était mon projet, je ferais le hachage au niveau de la couche d'application, puis je le passerais pour rechercher dans le magasin (cache, puis base de données).
"Existe-t-il une approche radicalement différente pour stocker/rechercher de longues chaînes dans une base de données ?"
- Comme je l'ai mentionné, je pense que pour votre objectif spécifique, la solution que vous proposez est bonne.
Tableau des recommandations (uniquement démonstratif) :
user
- id int(11) unsigned not null
- name_first varchar(100) non nul
user_agent_history
user_idint(11) non signé non nulagent_hashvarchar(255) non nul
agent
agent_hashvarchar(255) non nulbrowservarchar(100) non nulagenttexte non nul
Quelques notes sur le schéma :
-
D'après votre OP, il semble que vous ayez besoin d'une relation M:M entre l'utilisateur et l'agent, car un utilisateur peut utiliser Firefox au travail, mais peut ensuite passer à IE9 à la maison. D'où la nécessité du tableau croisé dynamique.
-
Le varchar(255) utilisé pour
agent_hashest à débattre. MySQL suggère en utilisant un type de colonne varbinary pour stocker les hachages, dont il existe plusieurs types. -
Je suggérerais également soit de faire
agent_hashune clé primaire, ou à tout le moins, en ajoutant une contrainte UNIQUE à la colonne.
