Ide Anda tentang hashing string panjang untuk membuat token yang akan dicari di dalam toko (cache, atau database) adalah ide yang bagus. Saya telah melihat ini dilakukan untuk string yang sangat besar, dan dalam lingkungan volume tinggi, dan ini berfungsi dengan baik.
"Hash mana yang akan Anda gunakan untuk aplikasi ini?"
- Menurut saya algoritma enkripsi (hashing) tidak terlalu penting, karena Anda tidak melakukan hashing untuk mengenkripsi data, Anda melakukan hashing untuk membuat token yang digunakan sebagai kunci untuk mencari nilai yang lebih panjang. Jadi pilihan algoritma hashing harus didasarkan pada kecepatan.
"Apakah Anda akan menghitung hash dalam kode atau membiarkan db menanganinya?"
- Jika ini adalah proyek saya, saya akan melakukan hashing pada lapisan aplikasi dan kemudian meneruskannya untuk mencari di dalam toko (cache, lalu database).
"Apakah ada pendekatan yang sangat berbeda untuk menyimpan/mencari string panjang dalam database?"
- Seperti yang saya sebutkan, saya pikir untuk tujuan spesifik Anda, solusi yang Anda usulkan adalah solusi yang bagus.
Rekomendasi tabel (hanya demonstratif):
user
- id int(11) tidak ditandatangani bukan nol
- nama_pertama varchar(100) bukan nol
user_agent_history
user_idint(11) tidak ditandatangani bukan nolagent_hashvarchar(255) bukan nol
agent
agent_hashvarchar(255) bukan nolbrowservarchar(100) bukan nolagentteks bukan nol
Sedikit catatan tentang skema:
-
Dari OP Anda, sepertinya Anda memerlukan hubungan M:M antara pengguna dan agen, karena fakta bahwa pengguna mungkin menggunakan Firefox dari kantor, tetapi kemudian dapat beralih ke IE9 di rumah. Oleh karena itu perlu adanya tabel pivot.
-
Varchar(255) digunakan untuk
agent_hashsiap untuk diperdebatkan. MySQL menyarankan menggunakan jenis kolom varbinary untuk menyimpan hash, yang ada beberapa jenisnya. -
Saya juga menyarankan untuk membuat
agent_hashkunci utama, atau paling tidak, menambahkan batasan UNIK ke kolom.
