Đầu tiên, giao diện người dùng: với tư cách là người dùng tôi ghét để tìm kiếm sản phẩm trong danh mục được tổ chức theo phân cấp nghiêm ngặt đường. Tôi không bao giờ nhớ được trong danh mục phụ phụ tiểu phụ ...- một sản phẩm "kỳ lạ" nằm trong danh mục nào và điều này buộc tôi phải lãng phí thời gian khám phá các danh mục "hứa hẹn" chỉ để khám phá ra rằng nó được phân loại trong a (đối với tôi, ít nhất là ) một cách lạ lùng.
Cái gì Kevin Peno gợi ý là một lời khuyên tốt và được gọi là duyệt theo khía cạnh . Như Marcia Bates đã viết trong After the Dot-Bomb :Lấy Thông tin Web Truy xuất Ngay Lúc này , " .. phân loại theo khía cạnh là phân loại theo thứ bậc vì cơ sở dữ liệu quan hệ là cơ sở dữ liệu phân cấp. ... ".
Về bản chất, tìm kiếm theo từng khía cạnh cho phép người dùng tìm kiếm danh mục của bạn bắt đầu từ bất kỳ "khía cạnh" nào họ thích và cho phép họ lọc thông tin bằng cách chọn các khía cạnh khác trong quá trình tìm kiếm. Lưu ý rằng, trái với cách hệ thống thẻ thường được hình thành, không có gì ngăn cản bạn tổ chức một số khía cạnh này theo thứ bậc.
Để nhanh chóng hiểu được nội dung của tìm kiếm theo từng khía cạnh, có một số bản trình diễn để khám phá tại Dự án giao diện tìm kiếm Flamenco - Giao diện tìm kiếm theo luồng .
Thứ hai, logic ứng dụng: cái gì Manitra
đề xuất cũng là một lời khuyên tốt (theo tôi hiểu), tức là tách các nút nodes và các liên kết nodes của một cây / đồ thị trong các quan hệ khác nhau. Những gì anh ấy gọi là "bảng tổ tiên" (tuy nhiên, đó là một cái tên trực quan hơn nhiều) được gọi là đóng theo hướng bắc cầu của một biểu đồ xoay chiều có hướng (DAG)
(quan hệ khả năng tiếp cận). Ngoài hiệu suất, nó còn đơn giản hóa các truy vấn rất nhiều, như Manitra đã nói.
Nhưng Tôi đề xuất một chế độ xem cho "bảng tổ tiên" như vậy (đóng bắc cầu), để các bản cập nhật theo thời gian thực và tăng dần, không theo định kỳ của một công việc hàng loạt. Có mã SQL (nhưng tôi nghĩ nó cần được điều chỉnh một chút cho phù hợp với các DBMS cụ thể) trong các bài báo mà tôi đã đề cập trong câu trả lời của mình cho ngôn ngữ truy vấn cho các tập đồ thị:câu hỏi lập mô hình dữ liệu . Cụ thể, hãy xem Duy trì Biểu đồ đóng theo phương thức bắc cầu trong SQL (.ps - tái bút).
Mối quan hệ Sản phẩm-Danh mục
Điểm đầu tiên của Manitra cũng đáng được nhấn mạnh.
Những gì anh ấy đang nói là giữa các sản phẩm và danh mục có một mối quan hệ nhiều-nhiều. Tức là:mỗi sản phẩm có thể thuộc một hoặc nhiều danh mục và trong mỗi danh mục có thể có 0 hoặc nhiều sản phẩm.
Ví dụ:các biến quan hệ đã cho sẵn (relvars) Sản phẩm và Danh mục có thể đại diện cho mối quan hệ đó như một máy tính relvar có ít nhất thuộc tính P # và C #, tức là số sản phẩm và danh mục (số nhận dạng) trong mối quan hệ khóa ngoại với Sản phẩm và Danh mục tương ứng số.
Điều này bổ sung cho việc quản lý hệ thống phân cấp của các danh mục. Tất nhiên, đây chỉ là bản phác thảo thiết kế.
Về duyệt theo khía cạnh trong SQL
Một khái niệm hữu ích để triển khai "duyệt theo từng khía cạnh" là phân chia quan hệ hoặc thậm chí là so sánh quan hệ (xem cuối trang được liên kết). I E. chia PC (Sản phẩm-Danh mục) theo danh sách (ngày càng tăng) các danh mục được chọn từ người dùng (điều hướng theo khía cạnh), người ta chỉ nhận được các sản phẩm trong các danh mục đó (tất nhiên, các danh mục được cho là không tất cả loại trừ lẫn nhau, nếu không chọn hai danh mục một sẽ không có sản phẩm nào).
DBMS dựa trên SQL thường thiếu các toán tử này (phân chia và so sánh), vì vậy tôi đưa ra một số tài liệu thú vị dưới đây để triển khai / thảo luận về chúng:
- BẰNG CÁCH THỰC HIỆN PHÂN BIỆT TOÀN QUỐC (.pdf từ Chỉ mục phiên FIE 2003 );
- Cách tiếp cận SQL đơn giản hơn (và tốt hơn) để phân chia quan hệ (.pdf từ Tạp chí Giáo dục Hệ thống Thông tin - Nội dung Tập 13, Số 2 (2002) );
- Xử lý các truy vấn khám phá tập phổ biến theo bộ phận và đặt toán tử kết hợp ngăn chặn ;
- Luật viết lại các truy vấn có chứa các nhà điều hành bộ phận ;
- Thuật toán và ứng dụng để định lượng phổ quát trong cơ sở dữ liệu quan hệ ;
- Tối ưu hóa Truy vấn với Định lượng Chung trong Hướng đối tượng và Cơ sở dữ liệu quan hệ đối tượng ;
- (Yêu cầu quyền truy cập ACM) Về độ phức tạp của phép chia và phép nối trong quan hệ đại số ;
- (Yêu cầu quyền truy cập ACM) Các thuật toán nhanh để định lượng phổ quát trong cơ sở dữ liệu lớn ;
và như vậy ...
Tôi sẽ không đi vào chi tiết ở đây nhưng sự tương tác giữa phân cấp danh mục và duyệt theo khía cạnh cần được chăm sóc đặc biệt.
Sai lệch về "độ phẳng"
Tôi đã xem nhanh bài viết được liên kết bởi Pras , Quản lý dữ liệu phân cấp trong MySQL , nhưng tôi đã ngừng đọc sau vài dòng này trong phần giới thiệu:
Để hiểu tại sao sự khăng khăng về quan hệ phẳng lặng này chỉ là vô nghĩa , hãy tưởng tượng một khối lập phương trong hệ tọa độ Descartes ba chiều :nó sẽ được xác định bởi 8 tọa độ (bộ ba), giả sử P1 (x1, y1, z1), P2 (x2, y2, z2), ..., P8 (x8, y8, z8) [ở đây chúng tôi không liên quan đến ràng buộc về các tọa độ này để chúng thực sự đại diện cho một khối lập phương].
Bây giờ, chúng ta sẽ đặt tập hợp các tọa độ (điểm) này vào một biến quan hệ và chúng ta sẽ đặt tên cho biến này là Points . Chúng tôi sẽ đại diện giá trị quan hệ của Points như bảng bên dưới:
Points| x | y | z |
=======+====+====+====+
| x1 | y1 | z1 |
+----+----+----+
| x2 | y2 | z2 |
+----+----+----+
| .. | .. | .. |
| .. | .. | .. |
+----+----+----+
| x8 | y8 | z8 |
+----+----+----+
Có phải khối lập phương này đang bị "san phẳng" chỉ bởi một hành động thể hiện nó theo cách lập bảng? Một quan hệ (giá trị) có giống với biểu diễn dạng bảng của nó không?
Một biến quan hệ giả định là các tập giá trị của các điểm trong không gian rời rạc n chiều, trong đó n là số thuộc tính quan hệ ("cột"). Đối với một không gian rời rạc n-chiều, "phẳng" có nghĩa là gì? Vô nghĩa thôi, như tôi đã viết ở trên.
Đừng hiểu sai ý tôi, Chắc chắn đúng là SQL là một ngôn ngữ được thiết kế tồi và các DBMS dựa trên SQL chứa đầy các đặc điểm riêng và thiếu sót (NULL, dự phòng, ...), đặc biệt là những ngôn ngữ xấu, DBMS-as- kiểu lưu trữ câm (không có ràng buộc tham chiếu, không có ràng buộc toàn vẹn, ...). Nhưng điều đó không liên quan gì đến những hạn chế tưởng tượng của mô hình dữ liệu quan hệ, ngược lại:họ quay lưng lại với nó nhiều hơn và kết quả là tệ hơn.
Đặc biệt, mô hình dữ liệu quan hệ, khi bạn đã hiểu nó, sẽ không có vấn đề gì trong việc biểu diễn bất kỳ cấu trúc nào, thậm chí cả phân cấp và đồ thị, như tôi đã trình bày chi tiết với các tham chiếu đến các bài báo đã xuất bản ở trên. Ngay cả SQL cũng có thể, nếu bạn che đậy những khiếm khuyết của nó, thiếu một cái gì đó tốt hơn.
Trên "Mô hình tập hợp lồng nhau"
Tôi đã đọc lướt phần còn lại của bài viết đó và tôi không đặc biệt ấn tượng bởi thiết kế logic như vậy:nó gợi ý trộn lẫn hai thực thể khác nhau, nút và liên kết , vào một mối quan hệ và điều này có thể sẽ gây ra sự khó xử. Nhưng tôi không muốn phân tích thiết kế đó kỹ hơn, xin lỗi.
CHỈNH SỬA: Stephan Eggermont đã phản đối, trong các bình luận bên dưới, rằng " Mô hình danh sách phẳng là một vấn đề. Đó là sự trừu tượng của việc triển khai khiến hiệu suất khó đạt được. ... ".
Bây giờ, chính xác thì quan điểm của tôi là:
- "mô hình danh sách phẳng" này là một điều tưởng tượng :chỉ vì một quan hệ được sắp xếp (biểu diễn) dưới dạng bảng ("danh sách phẳng") không có nghĩa là quan hệ đó là "danh sách phẳng" (một "đối tượng" và các biểu diễn của nó không giống nhau);
- biểu diễn logic (quan hệ) và chi tiết lưu trữ vật lý (phân rã ngang hoặc dọc, nén, chỉ mục (băm, b + cây, r-cây, ...), phân cụm, phân vùng, v.v.) là khác biệt; một trong những điểm của mô hình dữ liệu quan hệ ( RDM ) là tách lôgic khỏi mô hình "vật lý" (có lợi thế cho cả người dùng và người triển khai DBMS);
- hiệu suất là hệ quả trực tiếp của chi tiết lưu trữ vật lý (triển khai) và không về biểu diễn logic (Nhận xét của Eggermont là một ví dụ điển hình về nhầm lẫn logic-vật lý ).
Mô hình RDM không ràng buộc việc triển khai theo bất kỳ cách nào; một người có thể tự do triển khai các bộ giá trị và quan hệ khi người ta thấy phù hợp. Các mối quan hệ không nhất thiết phải tệp và bộ giá trị không nhất thiết phải hồ sơ của một tệp. Thư từ như vậy là một triển khai hình ảnh trực tiếp ngu ngốc .
Thật không may, triển khai DBMS dựa trên SQL là , quá thường xuyên, việc triển khai hình ảnh trực tiếp ngu ngốc và chúng có hiệu suất kém trong nhiều trường hợp - OLAP / ETL sản phẩm tồn tại để che những thiếu sót này.
Điều này đang dần thay đổi. Có phần mềm thương mại và miễn phí / triển khai mã nguồn mở cuối cùng tránh được cạm bẫy cơ bản này:
- Vertica , là sản phẩm kế thừa thương mại của ..
- C-Store:A Column-Oriented DBMS ;
- MonetDB ;
- LucidDB ;
- Kdb theo một cách nào đó;
- vân vân ...
Tất nhiên, vấn đề là không rằng phải tồn tại một thiết kế lưu trữ vật lý "tối ưu", nhưng bất kỳ thiết kế lưu trữ vật lý nào cũng có thể được trừu tượng hóa bằng một ngôn ngữ khai báo tốt đẹp dựa trên đại số quan hệ / tính toán (và SQL là một xấu ví dụ) hoặc trực tiếp hơn trên ngôn ngữ lập trình logic (chẳng hạn như Prolog - xem câu trả lời của tôi cho " trình chuyển đổi prolog sang SQL "câu hỏi). Một DBMS tốt phải được thay đổi thiết kế lưu trữ vật lý ngay lập tức, dựa trên thống kê truy cập dữ liệu (và / hoặc gợi ý của người dùng).
Cuối cùng, trong nhận xét của Eggermont, tuyên bố " Mô hình quan hệ đang được phát âm giữa đám mây và trình xử lý ưu thế. "là một điều vô nghĩa khác nhưng tôi không thể phản bác lại ở đây, nhận xét này đã quá dài.
