Phương pháp hay nhất để lưu trữ "tìm kiếm đã lưu" trong cơ sở dữ liệu

Question

Tôi đang làm việc trên trang tìm kiếm cho phép người dùng tìm kiếm nhà để bán. Tiêu chí tìm kiếm điển hình bao gồm giá/mã zip/# phòng ngủ/v.v.

Tôi muốn cho phép người dùng lưu tiêu chí này vào cơ sở dữ liệu và gửi email cho những ngôi nhà mới hàng ngày.

tôi có thể một trong hai:

1) Serialize một "SavedSearch" đối tượng vào một chuỗi và lưu rằng cơ sở dữ liệu, sau đó deserialize khi cần thiết.

2) Có danh sách các cột trong tblSavedSearch tương ứng với tiêu chí tìm kiếm - price/zip/# bedrooms/etc.

Tôi lo ngại nếu tôi chọn tùy chọn 1, tiêu chí tìm kiếm đã lưu của tôi sẽ thay đổi và để các đối tượng được tìm kiếm trong cơ sở dữ liệu không hợp lệ, nhưng tùy chọn 2 cũng không giống như giải pháp tối ưu.

Người khác đã giải quyết vấn đề này như thế nào?

Answer 1

Tôi giả sử bạn sẽ cần phải chạy lại tìm kiếm hàng ngày để tìm các bổ sung mới cho kết quả. Có thể đảm bảo rằng bạn tìm kiếm biểu mẫu chỉ định phương thức get để các tiêu chí tìm kiếm được nối vào url dưới dạng chuỗi truy vấn, sau đó lưu toàn bộ chuỗi truy vấn trong cơ sở dữ liệu.

Vì vậy, nếu bạn có một chương trình tìm kiếm được gọi là tìm kiếm.hành động mà bạn sẽ yêu cầu tìm kiếm như thế này:

search.action?price=20000&rooms=3 

Bạn có thể lưu giá = 20000 & phòng = 3 phần vào cơ sở dữ liệu. Để tìm kiếm này, bạn chỉ cần thêm chuỗi truy vấn vào url và yêu cầu trang tìm kiếm lại.

Thông báo trước chỉ là khi hành động tìm kiếm thay đổi, bạn phải thực hiện các cài đặt mặc định thông minh để tránh phá vỡ các tìm kiếm cũ. Ví dụ: giả sử bạn bắt đầu tìm kiếm theo màu, không có tìm kiếm cũ nào có tiêu chí màu để hành động tìm kiếm của bạn sẽ phải phục vụ cho điều này và đảm bảo rằng điều gì đó hợp lý như TẤT CẢ màu được sử dụng thay thế.

Answer 2

Nếu tôi có thể đề xuất, hãy có trang html có kết quả tìm kiếm (nếu nó chứa số lượng bản ghi vừa phải). Và, lưu trữ đường dẫn đến nó cùng với tiêu chí tìm kiếm trong DB

Điều này sẽ tránh truy vấn DB.

Chỉnh sửa: Tôi giả sử hồ sơ sẽ không thay đổi thường xuyên. Nếu có, tốt hơn là lưu trữ các tiêu chí tìm kiếm trong cơ sở dữ liệu và truy vấn nó khi được người dùng hỏi.

Answer 3

Người dùng bảng

Tiêu chuẩn bảng (= danh sách các tiêu chí tìm kiếm cung cấp)

bảng SavedSearch (chi tiết CỦA NGƯỜI SỬ DỤNG)

bảng SavedSearchCriteria, chi tiết của SavedSearch, tham khảo Tiêu chuẩn, cột SearchValue giữ giá trị do người dùng nhập cho mỗi tiêu chí đã nhập

Answer 4

Tôi sẽ đi với # 1. Nếu bạn thực sự lo lắng về các tiêu chí thay đổi, bạn có thể lưu trữ nó với thuộc tính "phiên bản tìm kiếm" và xoa bóp biểu diễn được tuần tự hóa khi cần.

# 2 sẽ không mở rộng thành bất kỳ loại tính hữu ích nào. Ví dụ, nếu bạn muốn làm bất kỳ loại boolean nhóm các tiêu chí tìm kiếm, lược đồ DB của bạn sẽ tự thắp sáng trên lửa và chạy la hét vào rừng.

Tôi thường giải quyết các sự cố tìm kiếm bằng cách nhấn mạnh việc lập chỉ mục/tìm kiếm trong cơ sở dữ liệu. Đó có thể là quá mức cần thiết cho những gì bạn đang nói về, nhưng RDBMS không phải là tuyệt vời cho việc tìm kiếm.

Answer 5

Bạn có thể lưu chính SQL động trong cơ sở dữ liệu dưới dạng chuỗi văn bản. Sau đó, bạn sẽ không phải làm tất cả các machinations tái tạo WHERE và IN và các SQL khác từ các cặp khóa-giá trị đã lưu.

Bạn có thể sử dụng SQL đã lưu và chạy nó khi bạn tạo email.

Nếu thiết kế cơ sở dữ liệu của bạn không đủ ổn định để lưu thông tin truy vấn, bạn có thể cần trì hoãn thiết kế tìm kiếm cho đến khi thiết kế cơ sở dữ liệu của bạn trưởng thành hơn.

Answer 6

Tôi nghĩ cả hai phương pháp tiếp cận đều hợp lý và tất cả phụ thuộc vào yêu cầu (hiện tại và tương lai).

Ví dụ: nếu số lượng tìm kiếm cao và nếu bạn cần phân tích chúng (ví dụ: câu hỏi trả lời như "Tần suất mọi người tìm kiếm mỗi số phòng ngủ?"), lưu trữ tìm kiếm và tiêu chí của chúng ở dạng quan hệ (tùy chọn của bạn # 2) sẽ phù hợp hơn.

Nhưng nếu bạn không có bất kỳ yêu cầu sắp xảy ra nào quyết định sử dụng tùy chọn # 2, thì không có gì sai với việc tuần tự hóa, IMHO. Chỉ cần đảm bảo rằng bạn KHÔNG phá vỡ tính tương thích với dữ liệu hiện có vì cấu trúc của các tiêu chí tìm kiếm của bạn thay đổi theo thời gian. (BTW, các vấn đề tương thích ngược không cụ thể với tùy chọn # 1 - chúng có thể xảy ra ngay cả khi sử dụng tùy chọn # 2.) Điểm mấu chốt là: bạn luôn có thể chuyển từ tùy chọn # 1 sang tùy chọn # 2 và bạn có thể trì hoãn việc chuyển đổi đó miễn là thực tế.

Answer 7

tôi sẽ còn thêm tầm nhìn dữ liệu đến các giải pháp ... cũng Users Bảng - chứa những người sử dụng Vai trò Bảng - chứa các vai trò n UserRoles db Bảng - một người sử dụng có thể có một hoặc nhiều vai trò tại một phiên họp Bảng MetaColumns - chứa thông tin meta cho tất cả các cột/khung nhìn trong db Bảng điều khiểnMetaColumns - mức hiển thị cho mỗi MetaColumn trên mỗi UserRole, người dùng sẽ luôn phải truy cập dữ liệu thực tế qua bảng này (INNER JOIN) Bảng TableViewToSearch - bảng hoặc xem để thực hiện tìm kiếm trên Bảng SavedSearch - Có Attributes ControllerMetaColumnsId, TableViewToSearchId, SavedSearchString - nếu Role không có quyền truy cập thuộc tính nó sẽ được cung cấp kết quả rỗng

Answer 8

Cách tốt nhất để thực hiện việc này là lưu trữ các tiêu chí tìm kiếm của bạn dưới dạng XML. Điều này sẽ cho phép bạn tham khảo các tiêu chí tìm kiếm của bạn một cách dễ dàng và cung cấp khả năng cho người dùng thay đổi nó nếu cần.

XML phải là giải pháp khả thi nhất và tôi sẽ tránh xa việc chuyển các tham số URL sang hành động. Nó có thể là một giải pháp đơn giản nhưng sẽ có những vấn đề sau.

1. Nếu người dùng muốn chỉnh sửa tiêu chí tìm kiếm mới thì chúng tôi phải thực hiện thao tác chuỗi quy mô lớn.

2. Lưu trữ tiêu chí tìm kiếm phức tạp sẽ là một vấn đề. Điều gì sẽ xảy ra nếu tôi muốn lưu một phức tạp và điều kiện. (Trong XML, kể từ khi nó đã được phân cấp, tôi chỉ có thể lưu trữ tất cả thông tin tôi cần).

3. Giải pháp có thể mở rộng và cũng sẽ khử trùng ứng dụng của bạn từ các cuộc tấn công Sql injection.

4. Vì XML là công nghệ đã trưởng thành nên bạn có thể sử dụng công nghệ này để thậm chí thực hiện xác thực trước khi chuyển nó vào đầu cuối.