Uw idee om lange strings te hashen om een token te maken waarop u in een winkel (cache of database) kunt zoeken, is een goed idee. Ik heb dit gezien voor extreem grote strings en in omgevingen met een hoog volume, en het werkt geweldig.
"Welke hash zou je voor deze applicatie gebruiken?"
- Ik denk niet dat het coderingsalgoritme (hashing) er echt toe doet, omdat je niet aan het hashen bent om gegevens te coderen, maar om een token te creëren dat als sleutel kan worden gebruikt om langere waarden op te zoeken. Dus de keuze van het hash-algoritme moet gebaseerd zijn op snelheid.
"Zou je de hash in code willen berekenen of de db het laten afhandelen?"
- Als het mijn project was, zou ik het hashen doen op de app-laag en het dan doorgeven om in de winkel op te zoeken (cache, dan database).
"Is er een radicaal andere benadering voor het opslaan/doorzoeken van lange strings in een database?"
- Zoals ik al zei, denk ik dat uw voorgestelde oplossing voor uw specifieke doel een goede is.
Tabelaanbevelingen (alleen ter demonstratie):
user
- id int(11) unsigned niet null
- name_first varchar(100) niet null
user_agent_history
user_idint(11) unsigned niet nullagent_hashvarchar(255) niet null
agent
agent_hashvarchar(255) niet nullbrowservarchar(100) niet nullagenttekst niet null
Enkele opmerkingen over het schema:
-
Vanuit je OP klinkt het alsof je een M:M-relatie tussen gebruiker en agent nodig hebt, vanwege het feit dat een gebruiker Firefox vanaf het werk gebruikt, maar thuis kan overschakelen naar IE9. Vandaar de noodzaak voor de draaitabel.
-
De varchar(255) gebruikt voor
agent_hashstaat ter discussie. MySQL suggereert een varbinair kolomtype gebruiken voor het opslaan van hashes, waarvan er verschillende soorten zijn. -
Ik zou ook aanraden om
agent_hash. te maken een primaire sleutel, of op zijn minst het toevoegen van een UNIEKE beperking aan de kolom.