Chúng tôi có một lượng lớn các tệp văn bản mà chúng tôi muốn tìm kiếm văn bản tự do / toàn văn bản, kết hợp với siêu dữ liệu có cấu trúc quan hệ về tệp văn bản. Vì vậy, một tìm kiếm có thể là "Đưa cho tôi tất cả các tệp thuộc nhóm X (hoặc nhóm phụ của X), có tác giả (Ari và Bari và Mari), thuộc về tổ chức Y và chứa văn bản" tổng hợp ". Phần sau là một tìm kiếm toàn văn và cái khác đã được lưu trữ dưới dạng dữ liệu quan hệ trong db hiện có của chúng tôi.
Trong cơ sở dữ liệu của chúng tôi (khá phức tạp), đã lưu trữ một cách để ID các tệp và một tấn siêu dữ liệu khác nhau về tệp, trải rộng giữa hàng chục bảng, từ các mối quan hệ 1-1 đơn giản, đến 1 bộ nhiều pr tệp và thậm chí mối quan hệ cấu trúc cây (những thứ như "tệp này là loại X, loại X là nhóm con loại Y, v.v.). Siêu dữ liệu này có thể thay đổi theo thời gian, trên toàn bộ ứng dụng (rất lớn).
Bây giờ, tôi với tư cách là quản trị viên cơ sở dữ liệu, đã nghĩ rằng điều này có thể được giải quyết bằng cách sử dụng SQL Server để thực hiện tìm kiếm siêu dữ liệu có cấu trúc đã có trong DB, hạn chế tìm kiếm các tệp ứng cử viên, sau đó chuyển id của tệp ứng cử viên để tìm kiếm đầy đủ tìm kiếm văn bản. (Lập chỉ mục lại tệp trên đàn hồi khi một tệp được thêm hoặc cam kết là không đáng kể trong mã của chúng tôi)
Tuy nhiên, những người đàn ông trong dự án của chúng tôi tự nhiên có một ý tưởng khác: Trích xuất tất cả dữ liệu meta cũng như nội dung toàn văn bản từ các tệp, để tìm kiếm đàn hồi và chạy tìm kiếm một cách linh hoạt.
Điều này cho phép họ chạy các truy vấn lucene được cung cấp đầy đủ một cách dễ dàng và tải được lấy ra khỏi cơ sở dữ liệu, điều này thật tuyệt. Tuy nhiên, điều này cũng với tôi, giới thiệu một cơn ác mộng để giữ cho siêu dữ liệu có cấu trúc được đồng bộ hóa và lập chỉ mục / đồng bộ hóa một cách mù quáng mọi thứ theo định kỳ là không thể do quy mô dữ liệu.
Tôi có thể thấy công đức / mối quan tâm cho cả hai lựa chọn. Có một thực hành tốt nhất cho loại điều này?
