Sự khác biệt giữa cơ sở dữ liệu dựa trên biểu đồ (http://neo4j.org/) và cơ sở dữ liệu hướng đối tượng (http://www.db4o.com/) là gì?Sự khác biệt giữa cơ sở dữ liệu dựa trên biểu đồ và cơ sở dữ liệu hướng đối tượng là gì?
Tôi sẽ trả lời điều này một cách khác nhau: cơ sở dữ liệu đối tượng và biểu đồ hoạt động trên hai mức trừu tượng khác nhau.
Một phần tử dữ liệu chính của cơ sở dữ liệu đối tượng là các đối tượng, cách chúng ta biết chúng từ ngôn ngữ lập trình hướng đối tượng.
Phần tử dữ liệu chính của cơ sở dữ liệu đồ thị là các nút và cạnh.
Cơ sở dữ liệu đối tượng không có khái niệm về cạnh (hai chiều) giữa hai thứ có tính toàn vẹn tham chiếu tự động, vv Cơ sở dữ liệu biểu đồ không có khái niệm về con trỏ có thể là NULL. (Tất nhiên người ta có thể tưởng tượng giống lai.)
Về mặt lược đồ, lược đồ của cơ sở dữ liệu đối tượng là bất kể tập hợp các lớp nào trong ứng dụng. Sơ đồ của cơ sở dữ liệu đồ thị (cho dù ngầm định, theo quy ước về nhãn Chuỗi có nghĩa là gì, hoặc rõ ràng, bằng cách khai báo như các mô hình như chúng ta làm trong ví dụ InfoGrid) là độc lập với ứng dụng. Điều này làm cho nó đơn giản hơn nhiều, ví dụ, để viết nhiều ứng dụng chống lại cùng một dữ liệu bằng cách sử dụng một cơ sở dữ liệu đồ thị thay vì một cơ sở dữ liệu đối tượng, bởi vì lược đồ là ứng dụng độc lập. Mặt khác, bằng cách sử dụng một cơ sở dữ liệu đồ thị, bạn không thể đơn giản lấy một đối tượng tùy ý và vẫn tồn tại nó.
Các công cụ khác nhau cho các công việc khác nhau mà tôi nghĩ.
Từ một trình duyệt nhanh chóng của cả hai trang web của họ:
Sự khác biệt chính là cách các API được cấu trúc, chứ không phải là các loại cơ sở dữ liệu dạng tự do bạn có thể xây dựng với họ.
db4o sử dụng ánh xạ đối tượng - bạn tạo một lớp Java/C# và nó sử dụng sự phản chiếu để duy trì nó trong cơ sở dữ liệu.
neo4j có API thao tác rõ ràng.
Neo4j dường như, theo quan điểm khiêm tốn của tôi, thú vị hơn nhiều khi tương tác.
Bạn cũng có thể xem xét kho khóa-giá trị - bạn có thể tạo chính xác cùng một cơ sở dữ liệu dạng tự do với một trong số đó.
Khi Will descibes từ một góc khác, graphdb sẽ giữ cho dữ liệu của bạn được tách biệt khỏi lớp ứng dụng và đối tượng của bạn. Graphdb cũng có nhiều chức năng tích hợp hơn để xử lý đồ thị, rõ ràng - như đường đi ngắn nhất hoặc đường đi ngang sâu.
Một khác biệt quan trọng là trong graphdb như neo4j bạn có thể duyệt biểu đồ dựa trên các loại mối quan hệ (cạnh) và hướng mà không tải các nút đầy đủ (bao gồm thuộc tính nút/thuộc tính). Ngoài ra còn có sự lựa chọn của việc sử dụng neo4j như phụ trợ của một đối tượng db, vẫn có thể sử dụng tất cả các công cụ đồ thị, xem: jo4neo Dự án này có một cách tiếp cận khác nhau mà cũng có thể tính là một đối tượng db trên đầu trang của neo4j: neo4j.rb. Một tùy chọn mới là sử dụng Spring Data Graph, cung cấp hỗ trợ graphdb thông qua chú thích.
Câu hỏi tương tự được đặt trong các nhận xét cho this blogpost.
Với cơ sở dữ liệu biểu đồ, bạn có một chút ngữ nghĩa về cơ hội dựa trên lý thuyết biểu đồ toán học. Với cơ sở dữ liệu hướng đối tượng, bạn có chắc chắn rằng nó dựa trên không có gì cả (và chắc chắn không có lý thuyết toán học nào cả).
Vâng, API có vẻ giống như sự khác biệt lớn, nhưng không thực sự là một sự hời hợt. Khái niệm một tập hợp các đối tượng sẽ tạo thành một biểu đồ và bạn có thể nghĩ về một API xử lý biểu đồ này một cách thống nhất. Ngược lại, trong lý thuyết bạn có thể khai thác một cấu trúc đồ thị chung cho các mẫu và ánh xạ chúng tới các đối tượng được lộ ra thông qua một số API. Tuy nhiên, thiết kế API của một sản phẩm thực tế thường sẽ có hậu quả về cách dữ liệu được lưu trữ thực sự, làm thế nào nó có thể được truy vấn, do đó, nó sẽ là xa tầm thường, nói, tạo ra một wrapper và làm cho nó trông giống như một cái gì đó khác. Ngoài ra, một cơ sở dữ liệu hướng đối tượng phải cung cấp một số đảm bảo tính toàn vẹn và một cấu trúc đánh máy mà một cơ sở dữ liệu đồ thị thường không làm. Trong thực tế, cơ sở dữ liệu OO nghiêm trọng nằm xa "dạng tự do" :)
Hãy xem [HyperGraphDB] [1] - nó là một cơ sở dữ liệu hướng đối tượng đầy đủ (như db4o) và cơ sở dữ liệu đồ thị rất tiên tiến về khả năng biểu diễn và truy vấn. Nó có khả năng lưu trữ các đồ thị tổng quát (nơi các cạnh có thể trỏ tới nhiều hơn một nút và cũng đến các cạnh khác), nó có một hệ thống kiểu mở rộng hoàn toàn được nhúng dưới dạng đồ thị, v.v.
Không giống như các cơ sở dữ liệu đồ thị khác, trong HyperGraphDB mỗi đối tượng trở thành một nút hoặc một cạnh trong biểu đồ, với sự xâm nhập API không tối thiểu và bạn có thể chọn đại diện cho các đối tượng của mình dưới dạng biểu đồ hoặc xử lý chúng theo cách trực giao với cấu trúc biểu đồ (dưới dạng "tải trọng" giá trị của các nút hoặc cạnh của bạn). Bạn có thể thực hiện các traversals tinh vi, lập chỉ mục tùy chỉnh và truy vấn.
Giải thích tại sao HyperGraphDB thực chất là một ODMS, hãy xem bài đăng trên blog Có phải HyperGraphDB là một Cơ sở dữ liệu OO không? tại trang web của Kobrix.
Sự khác biệt ở mức độ thấp không quá lớn. Cả hai đều quản lý các mối quan hệ dưới dạng các liên kết trực tiếp mà không phải tham gia tốn kém. Hơn nữa cả hai đều có một cách để đi qua các mối quan hệ với ngôn ngữ truy vấn, nhưng cơ sở dữ liệu đồ thị có các toán tử đi theo đệ quy ở cấp Nth.
Nhưng sự khác biệt lớn nhất là trong miền: trong cơ sở dữ liệu đồ thị, tất cả đều dựa trên 2 loại: đỉnh và cạnh, ngay cả khi bạn thường có thể xác định loại của riêng mình dưới dạng loại phụ của Vertex hoặc Edge.
Trong ODBMS bạn không có khái niệm Vertex và Edge, trừ khi bạn viết riêng của mình.