Din idé att hasha långa strängar för att skapa en token som du kan söka efter i en butik (cache eller databas) är bra. Jag har sett detta göras för extremt stora strängar, och inom högvolymmiljöer, och det fungerar utmärkt.
"Vilken hash skulle du använda för det här programmet?"
- Jag tror inte att krypteringsalgoritmen (hashing) spelar någon roll, eftersom du inte hashar för att kryptera data, du hashar för att skapa en token som du kan använda som nyckel för att slå upp längre värden. Så valet av hashalgoritm bör baseras på hastighet.
"Skulle du beräkna hashen i koden eller låta db hantera det?"
- Om det var mitt projekt skulle jag göra hash i applagret och sedan skicka igenom det för att leta upp i butiken (cache, sedan databasen).
"Finns det ett radikalt annorlunda tillvägagångssätt för att lagra/söka efter långa strängar i en databas?"
- Som jag nämnde tror jag att din föreslagna lösning är bra för ditt specifika syfte.
Tabellrekommendationer (endast demonstrerande):
user
- id int(11) osignerad inte null
- name_first varchar(100) inte null
user_agent_history
user_idint(11) osignerad inte nullagent_hashvarchar(255) inte null
agent
agent_hashvarchar(255) inte nullbrowservarchar(100) inte nullagenttext inte null
Några anteckningar om schema:
-
Från din OP låter det som att du behöver en M:M-relation mellan användare och agent, på grund av att en användare kanske använder Firefox från jobbet, men sedan kan byta till IE9 hemma. Därav behovet av pivottabellen.
-
Varchar(255) som används för
agent_hashär uppe för debatt. MySQL föreslår använder en varbinär kolumntyp för att lagra hash, av vilka det finns flera typer. -
Jag skulle också föreslå att du antingen gör
agent_hashen primärnyckel, eller åtminstone lägga till en UNIK begränsning till kolumnen.