Công cụ tìm kiếm mặt chuyên dụng để xử lý phân loại động - giúp chỉ với hiệu suất hoặc linh hoạt?

Question

Tôi đã suy nghĩ một lúc về mô hình hóa trang web thương mại điện tử điển hình với phân loại giống như ebay và các thuộc tính phụ thuộc vào một loại sản phẩm cụ thể.

Nỗ lực đầu tiên là lựa chọn giữa mô hình kế thừa EAV và Bảng Per Class DB. Tôi đã chọn thứ hai vì hiệu suất, nhưng ý nghĩa của việc tạo bảng chuyên dụng cho từng danh mục sản phẩm cụ thể (lá trong danh mục) với các thuộc tính danh mục cụ thể (như độ phân giải cho TV) được mô hình hóa thành một cột riêng biệt.

Trong khi trình diễn, thiết lập này không linh hoạt nếu bạn cần thêm thuộc tính vào danh mục hiện có hoặc thêm danh mục mới. Đối với mỗi sự thay đổi như vậy sau là cần thiết:

• Alter/tạo bảng
• hình thức mới để lọc withing loại như vậy bởi cụ thể thuộc tính
• Code mới để tạo ra các truy vấn db để tìm kiếm và lọc
• Một số viewmodels mới/DTO và lượt xem để giới thiệu sản phẩm từ các danh mục mới

Để đối phó với sự phức tạp đó, tôi nghĩ rằng một số loại đại diện meta của các thuộc tính đó là cần thiết (ngay cả bên ngoài ứng dụng) trong tệp xml hoặc thậm chí excel, sao cho mỗi thay đổi tất cả mã được đề cập có thể được tạo tự động (truy vấn sql/orm, mã ứng dụng, mẫu). Vì vậy, nó có thể giúp phát triển, nhưng vẫn còn thử nghiệm và triển khai thêm là cần thiết.

Vào thời điểm đó, tôi đã học được rằng ebay không thực sự sử dụng db quan hệ cho tìm kiếm và phân loại của chúng rất linh hoạt, chúng có thể nhanh chóng thêm các loại lá mới. Ngoài ra, các danh mục của chúng không phải là các danh mục từ một cây phân cấp được mô hình hoá trong db quan hệ, mà chỉ là các thuộc tính tìm kiếm (các khía cạnh).

Sau khi xem nhanh các thiết lập tìm kiếm mặt chuyên dụng đầy hứa hẹn nhất (ví dụ Solr riêng biệt) Tôi không chắc liệu nó có thể giúp tôi linh hoạt với các thay đổi phân loại hay không. sẽ vẫn phải được mô hình hóa trong DB dưới dạng siêu dữ liệu DBMS, ví dụ như. các biểu mẫu giao diện người dùng tạo động để lọc các thuộc tính sẽ khó trừ khi:

1) Tôi sẽ giữ dữ liệu trong RDBMS bằng cách sử dụng EAV fasion và khắc phục các vấn đề hiệu suất của nó bằng cách sử dụng tìm kiếm SOLR (nhưng vẫn có vấn đề với EAV messiness) thực thi tính toàn vẹn, vv)

2) Tôi sẽ chỉ giữ từ điển thuộc tính (nghĩa là tên và loại của chúng) trong RDBMS và lưu trữ các giá trị thuộc tính cụ thể trong SOLR sử dụng nó như một kho dữ liệu không quan hệ. . Tôi không tin vào giải pháp này (ngay cả khi có thể) vì ứng dụng sẽ được kết hợp chặt chẽ với solr (tức là quản trị viên phiên bản sản phẩm CRUD sẽ tương tác trực tiếp với SOLR).

Suy nghĩ của bạn là gì? Bạn có nghĩ rằng đối với bất kỳ loại thế hệ mã hóa tính linh hoạt phân loại (performant) như vậy là không thể tránh khỏi? Làm thế nào bạn sẽ xử lý điều đó? Có lẽ một số từ điển dữ liệu riêng biệt trong thời trang EAV trong DB chỉ dành cho mục đích tạo mã? Tôi đoán tôi cũng có thể sử dụng một cái gì đó như MongoDB, nhưng việc tạo mã UI (thời gian chạy hay không) vẫn sẽ cần một số loại siêu dữ liệu.

Có rất nhiều câu hỏi ở đây, nhưng tôi không muốn chia nhỏ thành các câu hỏi nhỏ vì tôi quan tâm đến cách tiếp cận thiết kế chung khi xử lý một lớp lớn hơn về các vấn đề như vậy.

Answer 1

Tôi không yêu cầu có câu trả lời dứt khoát cho tất cả điều này (đó là câu hỏi khá mở mà bạn nên cố gắng chia nhỏ thành phần nhỏ hơn và tùy thuộc vào yêu cầu thực tế của bạn bỏ phiếu để đóng nó) nhưng tôi sẽ bình luận về một vài điều:

1. Tôi sẽ quên cách tạo mô hình này trên RDBMS. Faceted search just doesn't work in a relational schema.
2. IMO đây không phải là nơi thích hợp để tạo mã. Bạn nên thiết kế mã của mình để mã không thay đổi với thay đổi dữ liệu (tôi không nói về lược đồ thay đổi).
3. Lưu trữ siêu dữ liệu/thuộc tính trên bảng tính Excel có vẻ như là một ý tưởng rất tồi. Tôi muốn xây dựng một giao diện người dùng để chỉnh sửa này, mà sẽ được lưu trữ trên Solr/MongoDB/CouchDB/bất cứ điều gì bạn chọn để quản lý này.
4. Solr không "chỉ quan hệ nhân bản DB". Trên thực tế, Solr hoàn toàn độc lập với các cơ sở dữ liệu quan hệ. Một trong những trường hợp phổ biến nhất là bán phá giá dữ liệu từ RDBMS sang Solr (không chuẩn hóa dữ liệu trong quy trình), nhưng Solr đủ linh hoạt để hoạt động mà không có bất kỳ nguồn dữ liệu quan hệ nào.
5. Hierarchical faceting in Solr vẫn là vấn đề mở trong nghiên cứu. Hiện nay có hai cách tiếp cận riêng biệt đang được nghiên cứu (SOLR-64, SOLR-792)

Answer 2

gì nếu bạn có các loại khác nhau của các loại với nhiều loại sản phẩm khác nhau?

Lấy ví dụ eBay, chúng ta sẽ phải Sản phẩm rằng có thể là Sách hoặc TV/Hiển thị.

Sách có tiêu đề và ISBN và có thể thuộc danh mục khoa học viễn tưởng hoặc trong danh mục khiêu dâm hoặc trong danh mục không phải tiểu thuyết hoặc danh mục tự truyện. Hoặc có thể bạn có một cuốn sách nằm trong danh mục khiêu dâm, tự truyện.

Hiển thị có độ phân giải màn hình và mức tiêu thụ watt (?) Và có thể nằm trong danh mục màn hình phẳng, danh mục CRT hoặc danh mục HD.

Từ một quan điểm hoàn toàn quan hệ của xem, bạn có thể lẽ mô hình này như sau:

[Product]-(1)------(1)-[ Book ]-(n)------(m)-[ book_category ] 
| id |    | title |    | name   | 
| price |    | ISBN | 
| ... | 
| ... |-(1)---(1)-[ display ]-(n)------(m)-[ display_category ] 
        | resolution |    | name   | 
        | watts | 

Thay vì mô hình attributes dependent on a particular product category, bạn sẽ có các thuộc tính khác nhau và loại phụ thuộc vào loại/lớp của sản phẩm.

Xem supertypes & subtypes