Идеята ви за хеширане на дълги низове за създаване на токен, по който да търсите в магазин (кеш или база данни) е добра. Виждал съм това да се прави за изключително големи струни и в среда с голям обем и работи чудесно.
„Кой хеш бихте използвали за това приложение?“
- Не мисля, че алгоритъмът за криптиране (хеширане) наистина има значение, тъй като не хеширате, за да шифровате данни, вие хеширате, за да създадете токен, върху който да използвате като ключ за търсене на по-дълги стойности. Така че изборът на алгоритъм за хеширане трябва да се основава на скоростта.
„Бихте ли изчислили хеша в кода или ще оставите db да го обработва?“
- Ако беше моят проект, щях да направя хеширането на слоя на приложението и след това да го прекарам, за да потърся в магазина (кеш, след това база данни).
„Има ли коренно различен подход за съхраняване/търсене на дълги низове в база данни?“
- Както споменах, мисля, че за вашата конкретна цел, предложеното от вас решение е добро.
Препоръки за таблица (само демонстративни):
user
- id int(11) unsigned not null
- name_first varchar(100) не е нула
user_agent_history
user_idint(11) unsigned not nullagent_hashvarchar(255) не е нула
agent
agent_hashvarchar(255) не е нулаbrowservarchar(100) не е нулаagentтекстът не е нулев.
Няколко бележки относно схемата:
-
От вашия OP звучи така, сякаш имате нужда от M:M връзка между потребител и агент, поради факта, че потребителят може да използва Firefox от работа, но след това може да премине към IE9 у дома. Оттук и необходимостта от централната таблица.
-
Varchar(255), използван за
agent_hashподлежи на дебат. MySQL предлага използване на варбиниран тип колона за съхранение на хешове, от които има няколко типа. -
Също така бих предложил да направите
agent_hashпървичен ключ или най-малкото добавяне на ограничение UNIQUE към колоната.
