La tua idea di eseguire l'hashing di stringhe lunghe per creare un token su cui cercare all'interno di un negozio (cache o database) è buona. L'ho visto fare per stringhe estremamente grandi e in ambienti ad alto volume e funziona alla grande.
"Quale hash useresti per questa applicazione?"
- Non credo che l'algoritmo di crittografia (hashing) sia davvero importante, poiché non stai eseguendo l'hashing per crittografare i dati, stai utilizzando l'hashing per creare un token su cui utilizzare come chiave per cercare valori più lunghi. Quindi la scelta dell'algoritmo di hashing dovrebbe basarsi sulla velocità.
"Vuoi calcolare l'hash nel codice o lasciare che sia il db a gestirlo?"
- Se fosse il mio progetto, farei l'hashing a livello di app e poi lo passerei per cercare all'interno dello store (cache, poi database).
"Esiste un approccio radicalmente diverso per l'archiviazione/ricerca di stringhe lunghe in un database?"
- Come ho detto, penso che per il tuo scopo specifico, la soluzione che hai proposto sia buona.
Consigli sulla tabella (solo dimostrativo):
user
- id int(11) unsigned non null
- name_first varchar(100) non null
user_agent_history
user_idint(11) unsigned non nullagent_hashvarchar(255) non null
agent
agent_hashvarchar(255) non nullbrowservarchar(100) non nullagenttesto non nullo
Poche note sullo schema:
-
Dal tuo OP sembra che tu abbia bisogno di una relazione M:M tra utente e agente, a causa del fatto che un utente potrebbe utilizzare Firefox dal lavoro, ma poi potrebbe passare a IE9 a casa. Da qui la necessità della tabella pivot.
-
Il varchar(255) usato per
agent_hashè in discussione. MySQL suggerisce utilizzando un tipo di colonna varbinary per la memorizzazione di hash, di cui esistono diversi tipi. -
Suggerirei anche di creare
agent_hashuna chiave primaria, o almeno, aggiungendo un vincolo UNIQUE alla colonna.
