Tại sao cơ sở dữ liệu quan hệ không hỗ trợ trả về thông tin theo định dạng lồng nhau?

Giả sử tôi đang xây dựng một blog mà tôi muốn có bài viết và bình luận. Vì vậy, tôi tạo hai bảng, bảng 'bài đăng' với cột 'id' số nguyên tự động và bảng 'nhận xét' có khóa ngoại 'post_id'.

Sau đó, tôi muốn chạy cái có lẽ sẽ là truy vấn phổ biến nhất của tôi, đó là lấy một bài đăng và tất cả các bình luận của nó. Là khá mới đối với cơ sở dữ liệu quan hệ, cách tiếp cận có vẻ rõ ràng nhất đối với tôi là viết một truy vấn trông giống như:

SELECT id, content, (SELECT * FROM comments WHERE post_id = 7) AS comments
FROM posts
WHERE id = 7

Điều này sẽ cung cấp cho tôi id và nội dung của bài đăng mà tôi muốn, cùng với tất cả các hàng nhận xét có liên quan được đóng gói gọn gàng trong một mảng (một đại diện lồng nhau như bạn sử dụng trong JSON). Tất nhiên, SQL và cơ sở dữ liệu quan hệ không hoạt động như thế này và gần nhất họ có thể nhận được là tham gia giữa 'bài đăng' và 'nhận xét' sẽ trả lại nhiều dữ liệu trùng lặp không cần thiết (với cùng một thông tin bài đăng được lặp lại trong mỗi hàng), có nghĩa là thời gian xử lý được dành cả trên cơ sở dữ liệu để kết hợp tất cả lại với nhau và trên ORM của tôi để phân tích và hoàn tác tất cả.

Ngay cả khi tôi hướng dẫn ORM của mình háo hức tải các bình luận của bài đăng, thì cách tốt nhất là gửi một truy vấn cho bài đăng, sau đó truy vấn thứ hai để lấy tất cả các bình luận, sau đó đặt chúng ở phía khách hàng cũng không hiệu quả.

Tôi hiểu rằng cơ sở dữ liệu quan hệ là công nghệ đã được chứng minh (địa ngục, chúng lớn hơn tôi) và rằng đã có rất nhiều nghiên cứu được đưa vào chúng trong nhiều thập kỷ và tôi chắc chắn có lý do thực sự tốt tại sao chúng (và Tiêu chuẩn SQL) được thiết kế để hoạt động theo cách họ làm, nhưng tôi không chắc tại sao cách tiếp cận tôi nêu ở trên là không thể. Nó dường như là cách đơn giản và rõ ràng nhất để thực hiện một trong những mối quan hệ cơ bản nhất giữa các hồ sơ. Tại sao cơ sở dữ liệu quan hệ không cung cấp một cái gì đó như thế này?

(Tuyên bố miễn trừ trách nhiệm: Tôi chủ yếu viết các ứng dụng web bằng cách sử dụng kho dữ liệu Rails và NoQuery, nhưng gần đây tôi đã dùng thử Postgres và tôi thực sự thích nó rất nhiều.

Tôi không hỏi làm thế nào để tối ưu hóa ứng dụng Rails, hay cách khắc phục vấn đề này trong một cơ sở dữ liệu cụ thể. Tôi đang hỏi tại sao tiêu chuẩn SQL hoạt động theo cách này khi nó có vẻ trái ngược và lãng phí đối với tôi. Phải có một số lý do lịch sử tại sao các nhà thiết kế ban đầu của SQL muốn kết quả của họ trông như thế này.

Ngày CJ đi sâu vào chi tiết về điều này trong Chương 7 và Phụ lục B của SQL và Lý thuyết quan hệ . Bạn nói đúng, không có gì trong lý thuyết quan hệ cấm loại dữ liệu của thuộc tính là chính mối quan hệ, miễn là nó có cùng loại quan hệ trên mỗi hàng. Ví dụ của bạn sẽ đủ điều kiện.

Nhưng Date nói rằng các cấu trúc như thế này là "thường - nhưng không phải lúc nào cũng bị chống chỉ định" (tức là một ý tưởng tồi) bởi vì hệ thống phân cấp của các mối quan hệ là không đối xứng . Ví dụ, một chuyển đổi từ cấu trúc lồng nhau sang cấu trúc "phẳng" quen thuộc không thể luôn luôn được đảo ngược để tạo lại lồng.

Các truy vấn, ràng buộc và cập nhật phức tạp hơn, khó viết hơn và RDBMS khó hỗ trợ hơn nếu bạn cho phép các thuộc tính có giá trị quan hệ (RVA).

Nó cũng làm vấy bẩn các nguyên tắc thiết kế cơ sở dữ liệu, bởi vì hệ thống phân cấp tốt nhất của các mối quan hệ không quá rõ ràng. Chúng ta có nên thiết kế mối quan hệ của Nhà cung cấp với RVA lồng nhau cho các bộ phận được cung cấp bởi Nhà cung cấp nhất định không? Hoặc mối quan hệ của các Bộ phận với RVA lồng nhau cho các nhà cung cấp cung cấp một Phần nhất định? Hoặc lưu trữ cả hai, để dễ dàng chạy các loại truy vấn khác nhau?

Đây là vấn đề nan giải tương tự xảy ra từ cơ sở dữ liệu phân cấp và các mô hình cơ sở dữ liệu hướng tài liệu . Cuối cùng, sự phức tạp và chi phí của việc truy cập các cấu trúc dữ liệu lồng nhau khiến các nhà thiết kế lưu trữ dữ liệu dư thừa để tìm kiếm dễ dàng hơn bằng các truy vấn khác nhau. Mô hình quan hệ không khuyến khích dự phòng, do đó, RVA có thể hoạt động chống lại các mục tiêu của mô hình quan hệ.

Từ những gì tôi hiểu (tôi chưa sử dụng chúng), Rel và Dataphor là các dự án RDBMS hỗ trợ các thuộc tính có giá trị quan hệ.

Nhận xét lại từ @dportas:

Các kiểu cấu trúc là một phần của SQL-99 và Oracle hỗ trợ các kiểu này. Nhưng họ không lưu trữ nhiều bộ dữ liệu trong bảng lồng nhau trên mỗi hàng của bảng cơ sở. Ví dụ phổ biến là một thuộc tính "địa chỉ" dường như là một cột duy nhất của bảng cơ sở, nhưng có thêm các cột phụ cho đường phố, thành phố, mã bưu chính, v.v.

Các bảng lồng nhau cũng được Oracle hỗ trợ và các bảng này cho phép nhiều bộ dữ liệu trên mỗi hàng của bảng cơ sở. Nhưng tôi không biết rằng đây là một phần của SQL chuẩn. Và hãy ghi nhớ kết luận của một blog: "Tôi sẽ không bao giờ sử dụng bảng lồng nhau trong câu lệnh CREATE TABLE. Bạn dành toàn bộ thời gian của mình để KIỂM TRA chúng để làm cho chúng hữu ích trở lại!"

Một số hệ thống cơ sở dữ liệu sớm nhất dựa trên mô hình Cơ sở dữ liệu phân cấp . Điều này thể hiện dữ liệu trong một cấu trúc giống như cây với cha mẹ và con cái, giống như bạn đang đề xuất ở đây. HDMS chủ yếu được thay thế bởi các cơ sở dữ liệu được xây dựng theo mô hình quan hệ. Lý do chính cho điều này là RDBMS có thể mô hình hóa các mối quan hệ "nhiều đến nhiều" gây khó khăn cho cơ sở dữ liệu phân cấp và RDBMS có thể dễ dàng thực hiện các truy vấn không phải là một phần của thiết kế ban đầu trong khi HDBMS buộc bạn phải truy vấn thông qua các đường dẫn được chỉ định tại thời điểm thiết kế.

Vẫn còn một số ví dụ về các hệ thống cơ sở dữ liệu phân cấp trong tự nhiên, đặc biệt là sổ đăng ký Windows và LDAP.

Phạm vi bao quát của chủ đề này có sẵn trong bài viết sau

Tôi cho rằng câu hỏi của bạn thực sự tập trung vào thực tế là trong khi cơ sở dữ liệu dựa trên logic vững chắc và đặt cơ sở trị liệu và họ làm rất tốt việc lưu trữ, thao tác và truy xuất dữ liệu trong các bộ (2 chiều) trong khi vẫn đảm bảo tính toàn vẹn tham chiếu, đồng thời và nhiều thứ khác, chúng không cung cấp tính năng (bổ sung) gửi dữ liệu (và nhận) theo cách mà người ta có thể gọi là định dạng hướng đối tượng hoặc định dạng phân cấp.

Sau đó, bạn tuyên bố rằng "ngay cả khi tôi hướng dẫn ORM của mình háo hức tải bình luận của bài đăng, cách tốt nhất là gửi một truy vấn cho bài đăng, sau đó truy vấn thứ hai để truy xuất tất cả các bình luận, sau đó đặt chúng lại với nhau phía khách hàng, cũng không hiệu quả " .

Tôi không thấy bất cứ điều gì không hiệu quả trong việc gửi 2 truy vấn và nhận 2 lô kết quả với:

--- Query-1-posts
SELECT id, content 
FROM posts
WHERE id = 7


--- Query-2-comments
SELECT * 
FROM comments 
WHERE post_id = 7

Tôi cho rằng đó là (gần như) cách hiệu quả nhất (gần như, vì bạn không thực sự cần posts.idvà không phải tất cả các cột từ đó comments.*)

Như Todd đã chỉ ra trong nhận xét của mình, bạn không nên yêu cầu cơ sở dữ liệu trả về dữ liệu sẵn sàng để hiển thị. Đó là công việc của ứng dụng để làm điều đó. Bạn có thể viết (một hoặc một vài) truy vấn để nhận kết quả bạn cần cho mọi thao tác hiển thị để không có sự trùng lặp không cần thiết trong dữ liệu được gửi qua dây (hoặc bus bộ nhớ) từ db đến ứng dụng.

Tôi không thể nói về ORM thực sự nhưng có lẽ một số người trong số họ có thể làm một phần công việc này cho chúng tôi.

Các kỹ thuật tương tự có thể được sử dụng trong việc phân phối dữ liệu giữa máy chủ web và máy khách. Các kỹ thuật khác (như bộ nhớ đệm) được sử dụng để cơ sở dữ liệu (hoặc web hoặc máy chủ khác) không bị quá tải với các yêu cầu trùng lặp.

Tôi đoán là các tiêu chuẩn, như SQL, là tốt nhất nếu chúng duy trì chuyên môn trong một lĩnh vực và không cố gắng bao quát tất cả các lĩnh vực của một lĩnh vực.

Mặt khác, phần thưởng đặt ra tiêu chuẩn SQL cũng có thể nghĩ khác trong tương lai và cung cấp sự phù hợp cho một tính năng bổ sung như vậy. Nhưng nó không phải là thứ có thể được thiết kế trong một đêm.

Tôi không thể trả lời bằng một câu trả lời đúng, có lý lẽ, vì vậy hãy thoải mái hạ bệ tôi vào quên lãng nếu tôi sai (nhưng xin vui lòng sửa cho tôi để chúng tôi có thể học được điều gì đó mới). Tôi nghĩ rằng lý do là các cơ sở dữ liệu quan hệ được tập trung vào mô hình quan hệ, đến lượt nó dựa trên một cái gì đó tôi không biết gì về "logic thứ tự đầu tiên". Những gì bạn có thể yêu cầu có thể không phù hợp về mặt khái niệm trong cơ sở dữ liệu quan hệ khung toán học / logic được xây dựng dựa trên. Hơn nữa, những gì bạn yêu cầu thường được giải quyết dễ dàng bằng cơ sở dữ liệu đồ thị, đưa ra nhiều gợi ý rằng đó là khái niệm cơ bản của cơ sở dữ liệu mâu thuẫn với những gì bạn muốn đạt được.

Tôi biết ít nhất SQLServer không hỗ trợ các truy vấn lồng nhau khi bạn sử dụng FOR XML.

SELECT id, content, (SELECT * FROM comments WHERE post_id = posts.id FOR XML PATH('comments'), TYPE) AS comments
FROM posts
WHERE id = 7
FOR XML PATH('posts')

Vấn đề ở đây không phải là thiếu sự hỗ trợ từ RDBMS, mà là thiếu sự hỗ trợ của các bảng lồng nhau trong các bảng.

Bên cạnh, điều gì ngăn bạn sử dụng một tham gia bên trong?

SELECT id, content, comments.*
FROM posts inner join comments on comments.post_id = posts.id
WHERE id = 7

Bạn thực sự có thể xem liên kết bên trong dưới dạng bảng lồng nhau, chỉ có nội dung của 2 trường đầu tiên được lặp lại một lần có thể. Tôi sẽ không lo lắng về hiệu suất của việc tham gia nhiều, phần chậm duy nhất trong truy vấn như thế này là io từ cơ sở dữ liệu đến máy khách. Đây sẽ chỉ là một vấn đề khi nội dung chứa một lượng lớn dữ liệu. Trong trường hợp đó tôi sẽ đề xuất hai truy vấn, một với select id, contentvà một với nối bên trong và select posts.id, comments.*. Tỷ lệ này thậm chí với nhiều bài đăng, vì bạn vẫn sẽ chỉ sử dụng 2 truy vấn.

Trên thực tế, Oracle hỗ trợ những gì bạn muốn nhưng bạn cần bọc truy vấn phụ bằng từ khóa "con trỏ". Kết quả được tìm nạp thông qua con trỏ mở. Trong Java, ví dụ các bình luận sẽ hiển thị dưới dạng tập kết quả. Thông tin thêm về điều này xem tài liệu của Oracle về "Biểu hiện HIỆN TẠI"

SELECT id, content, cursor(SELECT * FROM comments WHERE post_id = 7) AS comments
FROM posts
WHERE id = 7

Một số làm hỗ trợ lồng nhau (phân cấp).

Nếu bạn muốn một truy vấn, bạn có thể có một bảng tự tham chiếu chính nó. Một số RDMS hỗ trợ khái niệm này. Ví dụ: với SQL Server, người ta có thể sử dụng Biểu thức bảng chung (CTE) cho truy vấn phân cấp.

Trong trường hợp của bạn, Bài viết sẽ ở Cấp độ 0 và sau đó tất cả các nhận xét sẽ ở Cấp độ 1.

Các tùy chọn khác là 2 truy vấn hoặc Tham gia với một số thông tin bổ sung cho mỗi bản ghi được trả về (mà những người khác đã đề cập).

Ví dụ về phân cấp:

https://stackoverflow.com/questions/14274942/sql-server-cte-and-recursion-example

Trong liên kết trên, EmpLevel hiển thị mức độ lồng nhau (hoặc phân cấp).

Tôi xin lỗi tôi không chắc tôi hiểu chính xác vấn đề của bạn.

Trong MSSQL, bạn chỉ có thể thực thi 2 Báo cáo SQL.

SELECT id, content
FROM posts
WHERE id = 7

SELECT * FROM comments WHERE post_id = 7

Và nó sẽ trả về 2 bộ kết quả của bạn cùng một lúc.

RDBM dựa trên lý thuyết và chúng bám sát lý thuyết. Điều này cho phép một số tính nhất quán tốt đẹp và độ tin cậy đã được chứng minh về mặt toán học.

Bởi vì mô hình này đơn giản và một lần nữa dựa trên lý thuyết, nó giúp mọi người dễ dàng thực hiện tối ưu hóa và nhiều triển khai. Điều này không giống như NoQuery nơi mọi người làm nó hơi khác nhau.

Trước đây đã có những nỗ lực để tạo cơ sở dữ liệu phân cấp nhưng IIRC (dường như không thể google nó) đã có vấn đề (chu kỳ và sự bình đẳng xuất hiện trong tâm trí).

Bạn có một nhu cầu cụ thể. Nó sẽ được ưu tiên trích xuất dữ liệu ra khỏi cơ sở dữ liệu theo định dạng bạn muốn, vì vậy bạn có thể làm với nó những gì bạn muốn.

Một số điều cơ sở dữ liệu không làm tốt như vậy, nhưng dù sao việc xây dựng chúng để làm điều đó không phải là không thể. Rời khỏi việc hình thành các ứng dụng khác là khuyến nghị hiện tại, nhưng không thể giải thích được tại sao nó không thể được thực hiện.

Lập luận duy nhất tôi có chống lại đề nghị của bạn là có thể xử lý kết quả này được đặt theo cách "sql". Sẽ là một ý tưởng tồi khi tạo ra một kết quả trong cơ sở dữ liệu mà không thể làm việc với nó hoặc thao tác với nó ở một mức độ nào đó. Giả sử tôi đã tạo một chế độ xem được xây dựng theo cách bạn đề xuất, làm cách nào để đưa nó vào một tuyên bố chọn khác? Cơ sở dữ liệu muốn lấy kết quả và làm mọi thứ với chúng. Làm thế nào tôi có thể tham gia nó vào một bảng khác? Làm thế nào tôi có thể so sánh kết quả của bạn với một cái khác?

Sau đó, lợi ích của RDMS là tính linh hoạt của sql. Cú pháp chọn dữ liệu từ một bảng khá gần với danh sách người dùng hoặc các đối tượng khác trong hệ thống (Ít nhất đó là mục tiêu.). Không chắc chắn có bất kỳ điểm nào để làm một cái gì đó hoàn toàn khác biệt. Họ thậm chí còn không đưa họ đến điểm xử lý mã / con trỏ thủ tục hoặc BLOBS dữ liệu rất hiệu quả.

Theo tôi, phần lớn là do SQL và cách thức thực hiện các truy vấn tổng hợp - các hàm tổng hợp và nhóm được thực hiện trên các hàng 2 chiều lớn để trả về kết quả. Đó là cách nó đã có từ đầu và nó rất nhanh (hầu hết các giải pháp NoQuery khá chậm với tổng hợp và dựa vào lược đồ không chuẩn hóa thay vì các truy vấn phức tạp)

Tất nhiên PostgreSQL có một số tính năng từ cơ sở dữ liệu hướng đối tượng. Theo thư này ( tin nhắn ), bạn có thể đạt được những gì bạn cần bằng cách tạo tổng hợp tùy chỉnh.

Cá nhân tôi đang sử dụng các khung như Doctrine ORM (PHP) để thực hiện các tính năng hỗ trợ và ứng dụng tổng hợp như tải nhanh để tăng hiệu suất.

PostgreSQL hỗ trợ nhiều loại dữ liệu có cấu trúc, bao gồm Mảng và JSON . Sử dụng SQL hoặc một trong các ngôn ngữ thủ tục được nhúng, bạn có thể xây dựng các giá trị với cấu trúc phức tạp tùy ý và trả chúng về ứng dụng của bạn. Bạn cũng có thể tạo các bảng với các cột thuộc bất kỳ loại có cấu trúc nào, mặc dù vậy bạn nên xem xét cẩn thận xem bạn có cần thiết không chuẩn hóa thiết kế của mình không.