Sự khác biệt giữa Cơ sở dữ liệu quan hệ và không quan hệ là gì?


82

Tôi biết rằng các giải pháp như MySQL, PostgreSQL và MS SQL Server là hệ thống cơ sở dữ liệu quan hệ và NoSQL, MongoDB, v.v. là DBMS không quan hệ.

Tuy nhiên, sự khác biệt giữa hai loại hệ thống là gì?

Tốt hơn là các thuật ngữ cư sĩ.

Cảm ơn.


11
Đây không phải là bài tập về nhà ... nhưng hôm nay tôi đang cố gắng giải thích sự khác biệt cho một người bạn và kinda bắt đầu trống rỗng. Vì vậy, tôi nghĩ rằng tôi sẽ tìm kiếm ở đây và không tìm thấy bất kỳ lời giải thích thỏa mãn nào. Vì vậy, tôi sẽ hỏi. Sự khác biệt mà tôi đã nói là với RDBMS có rất nhiều bảng và các phép nối giữa các bảng. NoSQL không có nhiều bảng, nó chỉ có một bảng và sử dụng các cặp giá trị khóa. Không chắc đây có phải là một mô tả chính xác hay không, vì vậy tôi đã nghĩ rằng tôi sẽ hỏi.
marcamillion

Tôi thấy những câu trả lời này vô ích vì họ dành quá nhiều thời gian để nói về mức độ khó của câu hỏi mà không thực sự trả lời câu hỏi. Sau khi đọc bài đăng trên blog này, tôi nghĩ ý tưởng chính là nosql tốt hơn sql dbs khi mở rộng quy mô tức là trở nên phân tán khi mở rộng quy mô tức là nhiều sức mạnh tính toán hơn trên một máy không còn là một lựa chọn nữa. Jamesserra.com/archive/2015/08/…
mbigras

Câu trả lời:


23

Cơ sở dữ liệu quan hệ có cơ sở toán học (lý thuyết tập hợp, lý thuyết quan hệ), được chắt lọc thành Ngôn ngữ truy vấn có cấu trúc SQL ==.

Nhiều dạng của NoSQL (ví dụ: dựa trên tài liệu, dựa trên đồ thị, dựa trên đối tượng, lưu trữ khóa-giá trị, v.v.) có thể có hoặc không dựa trên một lý thuyết toán học nền tảng duy nhất. Như S. Lott đã chỉ ra một cách chính xác, các kho lưu trữ dữ liệu phân cấp thực sự có cơ sở toán học. Điều tương tự cũng có thể được nói đối với cơ sở dữ liệu đồ thị .

Tôi không biết về ngôn ngữ truy vấn chung cho cơ sở dữ liệu NoSQL.


"không có nền tảng toán học như vậy"? Có thật không? Cơ sở dữ liệu phân cấp có vẻ khá toán học đối với tôi. So sánh chúng cũng tương đối đơn giản. Tôi nghĩ rằng những người làm cơ sở dữ liệu XML có một khóa khá chắc chắn về những gì có thể (và không thể) được thực hiện trong cơ sở dữ liệu phân cấp.
S.Lott

Có thể là sự thiếu hiểu biết của tôi hoặc sự đơn giản hóa quá mức tại nơi làm việc, S. Lott. Tôi sẽ tìm một tài liệu tham khảo.
duffymo

1
Tôi không phải là chuyên gia về vấn đề này, nhưng vì chúng đều là các kho dữ liệu có cấu trúc nên tôi tin rằng ít nhất một tập hợp con của SQL có thể được áp dụng cho bất kỳ mô hình nào. Đối với vấn đề đó, tôi thực sự thích cách Google đưa ra ngôn ngữ truy vấn đúng với SQL cho Big Table code.google.com/appengine/docs/python/datastore/… của họ . Thực sự làm cho mọi thứ dễ dàng hơn nhiều.
Filip Dupanović

43

Rất tiếc, không chắc câu hỏi của bạn là gì.

Trong tiêu đề bạn hỏi về Cơ sở dữ liệu (DB), trong khi trong phần nội dung văn bản, bạn hỏi về Hệ thống quản lý cơ sở dữ liệu (DBMS). Hai câu trả lời hoàn toàn khác nhau và yêu cầu những câu trả lời khác nhau.

DBMS là một công cụ cho phép bạn truy cập vào một DB.

Khác với bản thân dữ liệu, DB là khái niệm về cách dữ liệu đó được cấu trúc.

Vì vậy, giống như bạn có thể lập trình với phương pháp Đối tượng hướng với trình biên dịch không hỗ trợ OO, hoặc ngược lại, bạn có thể thiết lập cơ sở dữ liệu quan hệ không có RDBMS hoặc sử dụng RDBMS để lưu trữ dữ liệu không quan hệ.

Tôi sẽ tập trung vào Cơ sở dữ liệu quan hệ (RDB) có nghĩa là gì và để lại cuộc thảo luận về những gì hệ thống làm với những người khác.

Cơ sở dữ liệu quan hệ (khái niệm) là một cấu trúc dữ liệu cho phép bạn liên kết thông tin từ các 'bảng' khác nhau hoặc các loại nhóm dữ liệu khác nhau. Một nhóm dữ liệu phải chứa cái được gọi là khóa hoặc chỉ mục (cho phép xác định duy nhất bất kỳ đoạn dữ liệu nguyên tử nào trong nhóm). Các nhóm dữ liệu khác có thể tham chiếu đến khóa đó để tạo liên kết giữa các nguyên tử dữ liệu của chúng và nguyên tử được chỉ đến bởi khóa.

Một cơ sở dữ liệu không quan hệ chỉ lưu trữ dữ liệu mà không có cơ chế rõ ràng và có cấu trúc để liên kết dữ liệu từ các nhóm khác nhau với nhau.

Để thực hiện một lược đồ như vậy, nếu bạn có một tệp giấy với một chỉ mục và trong một tệp giấy khác, bạn tham khảo chỉ mục để có được thông tin liên quan, thì bạn đã triển khai một cơ sở dữ liệu quan hệ, mặc dù khá đơn giản. Vì vậy, bạn thấy rằng bạn thậm chí không cần máy tính (tất nhiên nó có thể trở nên tẻ nhạt rất nhanh nếu không có ai trợ giúp), tương tự như vậy bạn không cần RDBMS, mặc dù được cho là RDBMS là công cụ phù hợp cho công việc. Điều đó nói rằng có nhiều biến thể về những gì mà các công cụ khác nhau có thể làm, do đó việc lựa chọn công cụ phù hợp cho công việc có thể không đơn giản như vậy.

Tôi hy vọng đây là thuật ngữ giáo dân đủ và hữu ích cho sự hiểu biết của bạn.


"Nếu bạn có một tệp giấy với một chỉ mục và trong một tệp giấy khác, bạn tham khảo chỉ mục để có được thông tin liên quan, thì bạn đã triển khai một cơ sở dữ liệu quan hệ" ví dụ rất tốt. Sẽ rất tuyệt nếu điều này được mở rộng hơn nữa để giải thích khóa chính, khóa ngoại, v.v.
Zeni

Người ta không cần biết về các ràng buộc hoặc khai báo bất kỳ hoặc có bất kỳ điều gì cần khai báo (bao gồm PK, CK & FK) để sử dụng cơ sở dữ liệu quan hệ. Chúng dành cho sự chính trực. Các bảng biểu thị quan hệ (tàu) s. Tham gia & các toán tử khác kết nối các bảng để nhận các bảng mới có quan hệ (tàu) là sự kết hợp của quan hệ đối số của bảng (tàu). Ngoài ra, các chỉ mục dành cho việc tối ưu hóa triển khai và không liên quan đến cơ sở dữ liệu / DBMS có quan hệ với người dùng của nó.
philipxy,

22

Hầu hết những gì bạn "biết" đều sai.

Trước hết, như một số chuyên gia về quan hệ thường xuyên (và đôi khi cứng nhắc) chỉ ra, SQL không thực sự phù hợp gần như chặt chẽ với lý thuyết quan hệ như nhiều người vẫn nghĩ. Thứ hai, hầu hết sự khác biệt trong nội dung "NoSQL" tương đối ít liên quan đến việc nó có quan hệ hay không. Cuối cùng, khá khó để nói "NoSQL" khác với SQL như thế nào vì cả hai đều đại diện cho một loạt các khả năng.

Một điểm khác biệt chính mà bạn có thể tin tưởng là hầu hết mọi thứ hỗ trợ SQL đều hỗ trợ những thứ như trình kích hoạt trong chính cơ sở dữ liệu - tức là bạn có thể thiết kế các quy tắc vào cơ sở dữ liệu phù hợp nhằm đảm bảo rằng dữ liệu luôn nhất quán nội bộ. Ví dụ: bạn có thể thiết lập mọi thứ để cơ sở dữ liệu của bạn khẳng định rằng một người phảicó một địa chỉ. Nếu bạn làm như vậy, bất cứ khi nào bạn thêm một người, về cơ bản, nó sẽ buộc bạn phải liên kết người đó với một số địa chỉ. Bạn có thể thêm một địa chỉ mới hoặc bạn có thể liên kết chúng với một số địa chỉ hiện có, nhưng bằng cách này hay cách khác, người đó phải có một địa chỉ. Tương tự như vậy, nếu bạn xóa một địa chỉ, nó sẽ buộc bạn phải xóa tất cả những người hiện đang ở địa chỉ đó hoặc liên kết mỗi người với một số địa chỉ khác. Bạn cũng có thể làm như vậy đối với các mối quan hệ khác, chẳng hạn như nói mỗi người phải có mẹ, mỗi văn phòng phải có số điện thoại, v.v.

Lưu ý rằng những thứ như thế cũng được đảm bảo để xảy ra atomically, vì vậy nếu ai đó nhìn khác tại cơ sở dữ liệu như bạn đang thêm người, họ sẽ hoặc là không nhìn thấy người ở tất cả, nếu không họ sẽ thấy người với các địa chỉ (hoặc mẹ, v.v.)

Hầu hết các cơ sở dữ liệu NoSQL không cố gắng cung cấp loại thực thi này trong cơ sở dữ liệu thích hợp. Tùy thuộc vào bạn, trong mã sử dụng cơ sở dữ liệu, để thực thi bất kỳ mối quan hệ nào cần thiết cho dữ liệu của bạn. Trong hầu hết các trường hợp, bạn cũng có thể thấy dữ liệu chỉ đúng một phần, vì vậy, ngay cả khi bạn có một cây phả hệ nơi mọi người được cho là có liên hệ với cha mẹ, có thể đôi khi bất kỳ ràng buộc nào bạn đã áp đặt sẽ không thực sự có. được thực thi. Một số sẽ cho phép bạn làm điều đó theo ý muốn. Những người khác đảm bảo rằng nó chỉ xảy ra tạm thời, mặc dù chính xác nó có thể / sẽ kéo dài bao lâu vẫn có thể được đặt câu hỏi.


9

Cơ sở dữ liệu quan hệ sử dụng một hệ thống vị từ chính thức để giải quyết dữ liệu. Việc triển khai vật lý cơ bản là không có bản chất và có thể thay đổi để tối ưu hóa cho các hoạt động nhất định, nhưng nó phải luôn giả định mô hình quan hệ . Theo thuật ngữ của giáo dân, điều đó chỉ nói rằng tôi biết chính xác có bao nhiêu giá trị (thuộc tính) mỗi hàng (tuple) trong bảng (mối quan hệ) của tôi và bây giờ tôi muốn khai thác thực tế một cách phù hợp, kỹ lưỡng và cực kỳ. Đó là bản chất thực sự của con thú. 

Vì chúng ta rõ ràng là thế hệ đã có sự giáo dục quan hệ, nếu bạn nhìn vào các mô hình cơ sở dữ liệu NoSQL từ góc độ của mô hình quan hệ, một lần nữa theo thuật ngữ của giáo dân, sự khác biệt rõ ràng đầu tiên là không có giả định nào về số lượng giá trị mà một hàng có thể chứa đã từng được thực hiện. Điều này thực sự đơn giản hóa vấn đề và không áp dụng rõ ràng cho sự phức tạp của các mô hình vật lý của mọi cơ sở dữ liệu NoSQL, nhưng đó là đỉnh cao của mô hình quan hệ và là giả định đầu tiên chúng ta phải bỏ lại phía sau hoặc giả thiết lớn nhất nếu bạn muốn chúng ta phải thực hiện bước nhảy vọt.

Chúng ta có thể đồng ý với hai điều đúng với mọi DBMS: nó có thể lưu trữ bất kỳ loại dữ liệu nào và có đủ cơ sở toán học để có thể quản lý dữ liệu theo bất kỳ cách nào có thể tưởng tượng được. Thực tế là bạn sẽ không bao giờ muốn mắc sai lầm khi đặt bất kỳ điểm nào trong hai điểm vào bài kiểm tra, mà chỉ cần gắn bó với những gì DBMS thực sự được tạo ra. Theo thuật ngữ của giáo dân: hãy tôn trọng con thú bên trong!

(Xin lưu ý rằng tôi đã tránh so sánh các tiêu chuẩn (rõ ràng) được xây dựng tốt xoay quanh mô hình quan hệ với nhiều loại được cung cấp bởi cơ sở dữ liệu NoSQL. Nếu bạn muốn, hãy coi cơ sở dữ liệu NoSQL như một thuật ngữ ô cho bất kỳ DBMS nào không hoàn toàn giả sử mô hình quan hệ, loại trừ mọi thứ khác. Sự khác biệt là quá nhiều, nhưng đó là sự khác biệt chính và là điều tôi nghĩ sẽ hữu ích nhất để bạn hiểu hai điều này.)


6

Cố gắng giải thích câu hỏi này ở mức đề cập đến một chút công nghệ

Lấy MongoDB và SQL truyền thống để so sánh, hãy tưởng tượng kịch bản đăng một Tweet trên Twitter. Tweet này có 9 hình ảnh. Làm thế nào để bạn lưu trữ tweet này và các hình ảnh tương ứng của nó?

Về mối quan hệ truyền thống SQL, bạn có thể lưu trữ các tweet và hình ảnh trong các bảng riêng biệt và thể hiện kết nối thông qua việc xây dựng một bảng mới.

Hơn nữa, bạn có thể đặt một trường là một loại hình ảnh và nén 9 hình ảnh vào một tài liệu nhị phân và lưu trữ trong trường này.

Sử dụng MongoDB, bạn có thể xây dựng một tài liệu như thế này (tương tự như khái niệm bảng trong SQL quan hệ):

{

"id":"XXX",

"user":"XXX",

"date":"xxxx-xx-xx",

"content":{

"text":"XXXX",

"picture":["p1.png","p2.png","p3.png"]

}

Do đó, theo tôi, sự khác biệt chính là về cách bạn lưu trữ dữ liệu và mức độ lưu trữ của các mối quan hệ giữa chúng.

Trong ví dụ này, dữ liệu là tweet và hình ảnh. Cơ chế khác nhau về mức độ lưu trữ của mối quan hệ giữa chúng cũng đóng một vai trò quan trọng trong sự khác biệt giữa cả hai.

Tôi hy vọng ví dụ nhỏ này giúp chỉ ra sự khác biệt giữa SQL và NoSQL (ACID và BASE).

Đây là một liên kết hình ảnh về các mục tiêu của NoSQL từ Internet:

http://icamchuwordpress-wordpress.stor.sinaapp.com/uploads/2015/01/dbc795f6f262e9d01fa0ab9b323b2dd1_b.png


giải thích thực sự tốt, có liên kết nơi tôi có ý tưởng đầu tiên, tôi hy vọng nó có thể giúp một số người. growthefuturenow.com/relational-vs-non-relational-database
Muhammad Sadiq

4

Sự khác biệt giữa quan hệ và không quan hệ chính xác là như vậy. Kiến trúc cơ sở dữ liệu quan hệ cung cấp các đối tượng ràng buộc như khóa chính, khóa ngoại, v.v. cho phép một liên kết hai hoặc nhiều bảng trong một quan hệ. Điều này là tốt để chúng ta chuẩn hóa các bảng của mình, tức là chia nhỏ thông tin về những gì cơ sở dữ liệu đại diện thành nhiều bảng khác nhau, một lần có thể giữ được tính toàn vẹn của dữ liệu.

Ví dụ: giả sử bạn có một loạt bảng chứa thông tin về một nhân viên. Bạn không thể xóa bản ghi khỏi một bảng mà không xóa tất cả các bản ghi liên quan đến bản ghi đó khỏi các bảng khác. Bằng cách này, bạn thực hiện toàn vẹn dữ liệu. Cơ sở dữ liệu không quan hệ không cung cấp các cấu trúc ràng buộc này sẽ cho phép bạn triển khai tính toàn vẹn của dữ liệu.

Trừ khi bạn không triển khai ràng buộc này trong ứng dụng giao diện người dùng được sử dụng để điền vào các bảng của cơ sở dữ liệu, bạn đang thực hiện một mớ hỗn độn có thể được so sánh với miền tây hoang dã.


1

Đầu tiên, hãy để tôi bắt đầu bằng cách nói lý do tại sao chúng ta cần một cơ sở dữ liệu.

Chúng tôi cần một cơ sở dữ liệu để giúp tổ chức thông tin theo cách mà chúng tôi có thể truy xuất dữ liệu được lưu trữ một cách hiệu quả.

Ví dụ về hệ quản trị cơ sở dữ liệu quan hệ (SQL):

1) Cơ sở dữ liệu Oracle

2) SQLite

3) PostgreSQL

4) MySQL

5) Máy chủ Microsoft SQL

6) IBM DB2

Ví dụ về hệ quản trị cơ sở dữ liệu không quan hệ (NoSQL)

1) MongoDB

2) Cassandra

3) Redis

4) Couchbase

5) HBase

6) Tài liệuDB

7) Neo4j

Cơ sở dữ liệu quan hệ có dữ liệu được chuẩn hóa, vì thông tin được lưu trữ trong bảng ở dạng hàng và cột, và thông thường khi dữ liệu ở dạng chuẩn hóa, nó sẽ giúp giảm dư thừa dữ liệu và dữ liệu trong bảng thường liên quan với nhau, vì vậy khi chúng tôi muốn truy xuất dữ liệu, chúng tôi có thể truy vấn dữ liệu bằng cách sử dụng câu lệnh nối và truy xuất dữ liệu theo nhu cầu của chúng tôi. Điều này phù hợp khi chúng tôi muốn có nhiều lần ghi hơn, ít lần đọc hơn và không có nhiều dữ liệu liên quan, nó cũng thực sự dễ dàng tương đối cập nhật dữ liệu trong bảng hơn trong cơ sở dữ liệu không quan hệ. Không thể mở rộng theo chiều ngang, có thể mở rộng theo chiều dọc ở một mức độ nào đó tuân thủ.CAP (Tính nhất quán, Tính khả dụng, Dung sai phân vùng) và ACID (Tính nguyên tử, Tính nhất quán, Cách ly, Thời lượng).

Hãy để tôi hiển thị việc nhập dữ liệu vào cơ sở dữ liệu quan hệ bằng cách sử dụng PostgreSQL làm ví dụ.

Đầu tiên tạo một bảng sản phẩm như sau:

CREATE TABLE products (
    product_no integer,
    name text,
    price numeric
);

sau đó chèn dữ liệu

INSERT INTO products (product_no, name, price) VALUES (1, 'Cheese', 9.99);

Hãy xem một ví dụ khác: nhập mô tả hình ảnh ở đây

Ở đây trong cơ sở dữ liệu quan hệ, chúng ta có thể liên kết bảng sinh viên và bảng chủ đề bằng cách sử dụng các mối quan hệ, thông qua khóa ngoại, ID môn học, nhưng trong cơ sở dữ liệu không quan hệ, không cần phải có hai tài liệu, vì không có mối quan hệ, vì vậy chúng tôi lưu trữ tất cả các chi tiết chủ đề và thông tin chi tiết về sinh viên trong một tài liệu cho biết tài liệu sinh viên, sau đó dữ liệu đang bị trùng lặp, điều này khiến việc cập nhật hồ sơ trở nên rắc rối.

Trong cơ sở dữ liệu không quan hệ, không có lược đồ cố định, dữ liệu không được chuẩn hóa. không có mối quan hệ nào giữa các dữ liệu được tạo ra, tất cả dữ liệu chủ yếu được đặt trong một tài liệu. Rất phù hợp khi xử lý nhiều dữ liệu và có thể chuyển nhiều dữ liệu cùng một lúc, tốt nhất khi số lượng đọc cao và ít ghi hơn, và ít cập nhật hơn, khó truy vấn dữ liệu một chút, vì không có lược đồ cố định. Có thể mở rộng quy mô theo chiều ngang và chiều dọc. Tuân thủAP (Tính nhất quán, Tính khả dụng, Khả năng chịu phân vùng) và BASE (Về cơ bản là có sẵn, trạng thái mềm, Cuối cùng nhất quán).

Hãy để tôi hiển thị một ví dụ để nhập dữ liệu vào cơ sở dữ liệu không quan hệ bằng Mongodb

db.users.insertOne({name: ‘Mary’, age: 28 , occupation: ‘writer’ })
db.users.insertOne({name: ‘Ben’ , age: 21})

Do đó, bạn có thể hiểu rằng đối với cơ sở dữ liệu được gọi là db và có một bộ sưu tập được gọi là người dùng và tài liệu được gọi là insertOne mà chúng tôi thêm dữ liệu và không có lược đồ cố định vì bản ghi đầu tiên của chúng tôi có 3 thuộc tính và thuộc tính thứ hai chỉ có 2 thuộc tính , điều này không có vấn đề gì trong cơ sở dữ liệu không quan hệ, nhưng điều này không thể thực hiện được trong cơ sở dữ liệu quan hệ, vì cơ sở dữ liệu quan hệ có một lược đồ cố định.

Hãy xem xét một ví dụ khác

({Studname: ‘Ash’, Subname: ‘Mathematics’, LecturerName: ‘Mr. Oak’})

Do đó, chúng ta có thể thấy trong cơ sở dữ liệu không quan hệ, chúng ta có thể nhập cả chi tiết sinh viên và chi tiết môn học vào một tài liệu, vì không có mối quan hệ nào được xác định trong cơ sở dữ liệu không quan hệ, nhưng ở đây, cách này có thể dẫn đến trùng lặp dữ liệu và do đó có thể xảy ra lỗi khi cập nhật.

Hy vọng điều này giải thích mọi thứ


-1

Theo thuật ngữ giáo dân, nó có cấu trúc mạnh mẽ so với không cấu trúc, điều này ngụ ý rằng bạn có các mức độ thích ứng khác nhau cho DB của mình. Sự khác biệt phát sinh trong việc lập chỉ mục, đặc biệt khi bạn cần đảm bảo rằng một chỉ mục tham chiếu nhất định có thể liên kết với một mục khác -> đây là một mối quan hệ. Cấu trúc chặt chẽ hơn của DB quan hệ xuất phát từ yêu cầu này.

Lưu ý rằng NosDB apaprently cung cấp cả DB quan hệ và không quan hệ và một cách để truy vấn cả http://www.alachisoft.com/nosdb/sql-cheat-sheet.html

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.