2011-01-27 88 views
70

Tôi biết rằng các giải pháp như MySQL, PostgreSQL và MS SQL Server là các hệ thống cơ sở dữ liệu quan hệ, và NoSQL, MongoDB, vv là các DBMS phi quan hệ.Sự khác biệt giữa Cơ sở dữ liệu Quan hệ và Không Quan hệ là gì?

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

Điều khoản Layman phù hợp hơn.

Cảm ơn.

+9

Đây không phải là bài tập về nhà ... nhưng hôm nay tôi đã cố gắng giải thích sự khác biệt với một người bạn và kinda bắt đầu trống rỗng. Vì vậy, tôi figured tôi sẽ tìm kiếm ở đây và đã không tìm thấy bất kỳ giải thích thỏa mãn. Vì vậy, figured tôi sẽ yêu cầu. Sự khác biệt tôi đã nói là với RDBMS có rất nhiều bảng và tham gia 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ặp giá trị khóa. Bạn không chắc chắn đây có phải là mô tả chính xác hay không, vì vậy tôi đã nghĩ tôi sẽ hỏi. – marcamillion

+5

Đây là một câu hỏi và không phải là một bài tập về nhà. – Narek

Trả lời

22

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

Không có nhiều biểu mẫu của NoSQL (ví dụ: dựa trên tài liệu, dựa trên biểu đồ, dựa trên đối tượng, khóa giá trị khóa, v.v.) có thể hoặc không thể dựa trên một lý thuyết toán học đơn giản. Như S. Lott đã chỉ ra một cách chính xác, hierarchical các kho dữ liệu thực sự có một cơ sở toán học. Điều tương tự có thể được nói cho graph databases.

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

+0

"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. Họ cũng tương đối đơn giản, bằng cách so sánh. Tôi nghĩ rằng các folks cơ sở dữ liệu XML có một khóa khá vững chắc về những gì có thể (và không thể) được thực hiện trong một cơ sở dữ liệu phân cấp. –

+0

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

+1

Tôi không có chuyên gia về vấn đề này, nhưng vì chúng là tất cả các kho dữ liệu có cấu trúc, 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 đã tiếp xúc với một ngôn ngữ truy vấn đúng với SQL cho Big Table của họ http://code.google.com/appengine/docs/python/datastore/gqlreference.html. Thực sự làm mọi thứ trở nên dễ dàng hơn nhiều. –

17

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

Trước hết, như một số ít các bậc thầy quan hệ thường xuyên (và đôi khi tự tin) chỉ ra, SQL không thực sự phù hợp chặt chẽ với lý thuyết quan hệ như nhiều người nghĩ. Thứ hai, hầu hết sự khác biệt trong công cụ "NoSQL" có 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 cách "NoSQL" khác với SQL vì cả hai đại diện cho một phạm vi khá rộng các khả năng. Một sự khác biệt lớn mà bạn có thể tin cậy 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 - nghĩa là bạn có thể thiết kế các quy tắc trong cơ sở dữ liệu phù hợp để đảm bảo rằng dữ liệu luôn ở trong nội bộ thích hợp. Ví dụ: bạn có thể thiết lập mọi thứ để cơ sở dữ liệu của bạn xác nhận rằng một người phải có đị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ó địa chỉ. Tương tự như vậy, nếu bạn xóa đị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 kết hợp từng địa chỉ với một số địa chỉ khác. Bạn có thể làm tương tự cho các mối quan hệ khác, chẳng hạn như nói rằng mọi người phải có một người mẹ, mỗi văn phòng đều phải có số điện thoại, v.v.

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

Hầu hết cơ sở dữ liệu NoSQL làm không cố gắng cung cấp loại thực thi này trong cơ sở dữ liệu phù 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ó cây gia đình, nơi mọi người được cho là có liên quan đến bố mẹ, có thể có những thời gian mà bạn đã áp đặt 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 bao lâu nó có thể/sẽ kéo dài có thể được mở cho câu hỏi.

38

Hmm, không hoàn toàn chắc chắn 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 ở 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 là hoàn toàn khác nhau và yêu cầu câu trả lời khác nhau.

DBMS là công cụ cho phép bạn truy cập DB.

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

Vì vậy, cũng giống như bạn có thể lập trình với phương pháp hướng đối tượng với trình biên dịch một tổ chức phi OO hỗ trợ, hoặc ngược lại, vì vậy bạn có thể thiết lập một cơ sở dữ liệu quan hệ mà không có một RDBMS hoặc sử dụng một 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à để thảo luận về những hệ thống nào làm cho người khác.

Cơ sở dữ liệu quan hệ (khái niệm) là 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. Thùng 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 ra một liên kết giữa các nguyên tử dữ liệu của chúng và nguyên tử được trỏ tới bằng khóa.

Cơ sở dữ liệu phi 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.

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

Tôi hy vọng đây là điều khoản của người đủ và hữu ích cho sự hiểu biết của bạn.

+0

"nếu bạn có tệp giấy có chỉ mục và trong tệp giấy khác, bạn tham khảo chỉ mục để lấy thông tin có liên quan, thì bạn đã triển khai cơ sở dữ liệu quan hệ" ví dụ rất tốt. Sẽ là tuyệt vời 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, vv – Zeni

+0

Một 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ỳ khai báo nào (bao gồm PK, CK và FK) để sử dụng cơ sở dữ liệu quan hệ. Chúng cho tính toàn vẹn. Các bảng biểu diễn quan hệ (ship) s. Tham gia & các toán tử khác kết nối các bảng để có được các bảng mới có quan hệ (ship) s là các kết hợp của các quan hệ bảng đối số (ship) s. Ngoài ra các chỉ mục là để 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

9

Cơ sở dữ liệu quan hệ sử dụng hệ thống chính thức của các vị từ để xử lý dữ liệu. Việc thực hiện vật lý cơ bản là không có chất và có thể thay đổi để tối ưu hóa cho các hoạt động nhất định, nhưng nó luôn luôn phải giả định relational model. Trong điều khoản của giáo dân, đó chỉ là nói 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 (quan hệ) của tôi có và bây giờ tôi muốn khai thác thực tế cho phù hợp, kỹ lưỡng và cực đoan. Đó là đúng bản chất của con thú. Vì chúng ta rõ ràng là thế hệ đã có một nền tảng quan hệ, nếu bạn nhìn vào các mô hình cơ sở dữ liệu NoSQL từ quan điểm của mô hình quan hệ, một lần nữa trong các 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 về số của các giá trị mà một hàng có thể chứa được bao giờ được tạo. Điều này thực sự đơn giản hóa vấn đề và không áp dụng một cách 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 nó là đỉnh cao của mô hình quan hệ và giả định đầu tiên chúng ta phải bỏ lại hoặc, nếu bạn muốn, bước nhảy vọt chúng ta phải làm.

Chúng tôi có thể đồng ý 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ó đủ nền tảng 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à đúng hơn là chỉ gắn bó với những gì mà DBMS thực sự đã thực sự tạo ra. Theo thuật ngữ của giáo dân: 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 xoay quanh mô hình quan hệ dựa trên nhiều hương vị do cơ sở dữ liệu NoSQL cung cấp. bất kỳ DBMS nào không hoàn toàn giả định mô hình quan hệ, trong sự loại trừ với 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à sự khác biệt mà tôi nghĩ là sẽ sử dụng nhiều nhất để bạn hiểu được hai điều này.)

4

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

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

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

Còn gì nữa, bạn có thể đặt trường là loại hình ảnh và zip 9 ảnh thành tài liệu nhị phân và lưu trữ nó 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 về một bảng trong SQL quan hệ):

{ 

"id":"XXX", 

"user":"XXX", 

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

"content":{ 

"text":"XXXX", 

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

} 

Vì vậy, theo ý kiến ​​của tôi, sự khác biệt chính là về làm thế nào để bạn lưu trữ các 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 hiển thị sự khác biệt giữa SQL và NoSQL (ACID và BASE).

Dưới đây là một liên kết của bức tranh về các mục tiêu của NoSQL từ Internet:

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

+0

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 hop nó có thể giúp một số một. http://growthefuturenow.com/relational-vs-non-relational-database/ –

3

Sự khác biệt giữa quan hệ và không quan hệ là chính xác điều đó. Kiến trúc cơ sở dữ liệu quan hệ cung cấp các ràng buộc các đối tượng như khóa chính, khóa ngoài, vv cho phép một đối tượng buộc hai hoặc nhiều bảng trong một quan hệ. Điều này là tốt để chúng tôi bình thường hóa các bảng của chúng tôi là để nói chia thông tin về những gì cơ sở dữ liệu đại diện cho nhiều bảng khác nhau, một khi có thể giữ sự 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ề nhân viên. Bạn không thể xóa bản ghi khỏi bảng mà không xóa tất cả các bản ghi liên quan đến bản ghi đó từ 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 thực hiện toàn vẹn dữ liệu. Trừ khi bạn không thực hiện ràng buộc này trong ứng dụng đầu cuối đượ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 phía tây hoang dã.

0

Tốt Relational Databases Thực hiện = Atomic Hầm chứa
Tốt Non Relational Databases Thực hiện = Wild Wild West

Trong trường hợp có thảm họa gây tử vong (bug/lỗi), nơi bạn sẽ được an toàn hơn? Nếu cuộc sống của tôi phụ thuộc vào dữ liệu được lưu trữ trong cơ sở dữ liệu, tôi sẽ chọn rõ ràng cơ sở dữ liệu quan hệ.

Tôi thấy không có giá trị trong sự kinkyness, tôi có nghĩa là điểm tái phát minh ra một bánh xe đã tròn và quay vòng là bằng chứng đạn là gì? Cũng xin chúc mừng @Jerry Coffin đã trả lời.

Các vấn đề liên quan