Ý tưởng của bạn về việc băm các chuỗi dài để tạo mã thông báo để tra cứu trong cửa hàng (bộ nhớ cache hoặc cơ sở dữ liệu) là một ý tưởng hay. Tôi đã thấy điều này được thực hiện đối với các chuỗi cực lớn và trong môi trường có âm lượng lớn và nó hoạt động rất tốt.
"Bạn sẽ sử dụng hàm băm nào cho ứng dụng này?"
- Tôi không nghĩ rằng thuật toán mã hóa (băm) thực sự quan trọng, vì bạn không băm để mã hóa dữ liệu, bạn đang băm để tạo mã thông báo dùng làm khóa để tra cứu các giá trị dài hơn. Vì vậy, việc lựa chọn thuật toán băm phải dựa trên tốc độ.
"Bạn sẽ tính toán mã băm trong mã hay để db xử lý nó?"
- Nếu đó là dự án của tôi, tôi sẽ thực hiện băm ở lớp ứng dụng và sau đó chuyển nó qua để tra cứu trong cửa hàng (bộ nhớ cache, sau đó là cơ sở dữ liệu).
"Có cách tiếp cận hoàn toàn khác để lưu trữ / tìm kiếm các chuỗi dài trong cơ sở dữ liệu không?"
- Như tôi đã đề cập, tôi nghĩ rằng đối với mục đích cụ thể của bạn, giải pháp bạn đề xuất là một giải pháp tốt.
Bảng khuyến nghị (chỉ mang tính minh họa):
user
- id int (11) unsigned not null
- name_first varchar (100) không null
user_agent_history
-
user_idint (11) unsigned not null -
agent_hashvarchar (255) không null
agent
-
agent_hashvarchar (255) không null -
browservarchar (100) không null -
agentvăn bản không rỗng
Vài lưu ý về lược đồ:
-
Từ OP của bạn, có vẻ như bạn cần mối quan hệ M:M giữa người dùng và tác nhân, do thực tế là người dùng có thể đang sử dụng Firefox từ nơi làm việc, nhưng sau đó có thể chuyển sang IE9 ở nhà. Do đó cần có bảng tổng hợp.
-
Varchar (255) được sử dụng cho
agent_hashlà để tranh luận. MySQL đề xuất sử dụng loại cột varbinary để lưu trữ các hàm băm, trong đó có một số loại. -
Tôi cũng khuyên bạn nên tạo
agent_hashmột khóa chính, hoặc ít nhất, thêm một ràng buộc DUY NHẤT vào cột.
