Twój pomysł na mieszanie długich ciągów w celu utworzenia tokenu, na podstawie którego można wyszukiwać w sklepie (pamięci podręcznej lub bazie danych), jest dobry. Widziałem to zrobione dla bardzo dużych strun i w środowiskach o dużej głośności, i działa to świetnie.
„Którego skrótu użyjesz w tej aplikacji?”
- Nie sądzę, aby algorytm szyfrowania (haszowania) miał naprawdę znaczenie, ponieważ nie haszujesz danych, tylko haszujesz, aby utworzyć token, który będzie używany jako klucz do wyszukiwania dłuższych wartości. Zatem wybór algorytmu haszującego powinien opierać się na szybkości.
„Czy obliczysz skrót w kodzie, czy pozwolisz, aby baza danych go obsłużyła?”
- Gdyby to był mój projekt, wykonałbym mieszanie w warstwie aplikacji, a następnie przepuściłby go, aby wyszukać w sklepie (pamięć podręczna, a następnie baza danych).
„Czy istnieje radykalnie inne podejście do przechowywania/przeszukiwania długich ciągów w bazie danych?”
- Jak wspomniałem, uważam, że dla Twojego konkretnego celu proponowane przez Ciebie rozwiązanie jest dobre.
Zalecenia dotyczące tabeli (tylko poglądowe):
user
- id int(11) unsigned nie null
- name_first varchar(100) nie jest null
user_agent_history
user_idint(11) unsigned nie nullagent_hashvarchar(255) nie null
agent
agent_hashvarchar(255) nie nullbrowservarchar(100) nie nullagenttekst nie jest pusty
Kilka uwag na temat schematu:
-
Z twojego OP wygląda na to, że potrzebujesz relacji M:M między użytkownikiem a agentem, ponieważ użytkownik może używać Firefoksa w pracy, ale potem może przełączyć się na IE9 w domu. Stąd potrzeba tabeli przestawnej.
-
varchar(255) używany do
agent_hashjest przedmiotem debaty. MySQL sugeruje używanie typu kolumny varbinary do przechowywania skrótów, których jest kilka typów. -
Sugerowałbym również wykonanie
agent_hashklucz podstawowy lub przynajmniej dodanie ograniczenia UNIQUE do kolumny.
