Su idea de codificar cadenas largas para crear un token sobre el cual buscar dentro de una tienda (caché o base de datos) es buena. He visto que esto se hace para cadenas extremadamente grandes y en entornos de gran volumen, y funciona muy bien.
"¿Qué hash usarías para esta aplicación?"
- No creo que el algoritmo de cifrado (hashing) realmente importe, ya que no está codificando para cifrar datos, está codificando para crear un token sobre el cual usar como clave para buscar valores más largos. Por lo tanto, la elección del algoritmo hash debe basarse en la velocidad.
"¿Calcularías el hash en el código o dejarías que la base de datos lo manejara?"
- Si fuera mi proyecto, haría el hash en la capa de la aplicación y luego lo pasaría para buscar dentro de la tienda (caché, luego base de datos).
"¿Existe un enfoque radicalmente diferente para almacenar/buscar cadenas largas en una base de datos?"
- Como mencioné, creo que para su propósito específico, la solución propuesta es buena.
Recomendaciones de tablas (solo demostrativas):
user
- id int(11) sin firmar, no nulo
- name_first varchar(100) no nulo
user_agent_history
user_idint(11) sin signo no nuloagent_hashvarchar(255) no nulo
agent
agent_hashvarchar(255) no nulobrowservarchar(100) no nuloagenttexto no nulo
Algunas notas sobre el esquema:
-
Desde su OP, parece que necesita una relación M:M entre el usuario y el agente, debido al hecho de que un usuario puede estar usando Firefox desde el trabajo, pero luego puede cambiar a IE9 en casa. De ahí la necesidad de la tabla dinámica.
-
El varchar(255) utilizado para
agent_hashestá en debate. MySQL sugerencias usando un tipo de columna varbinary para almacenar hashes, de los cuales hay varios tipos. -
También sugeriría hacer
agent_hashuna clave principal, o al menos, agregando una restricción ÚNICA a la columna.
