Tại sao tôi nên sử dụng cơ sở dữ liệu dựa trên tài liệu như CouchDB thay vì sử dụng cơ sở dữ liệu quan hệ. Có bất kỳ loại ứng dụng hoặc miền điển hình nào mà cơ sở dữ liệu dựa trên tài liệu phù hợp hơn cơ sở dữ liệu quan hệ không?
Câu trả lời:
Có lẽ bạn không nên :-)
Câu trả lời rõ ràng thứ hai là bạn nên sử dụng nó nếu dữ liệu của bạn không liên quan. Điều này thường thể hiện ở chỗ không có cách dễ dàng để mô tả dữ liệu của bạn dưới dạng một tập hợp các cột. Một ví dụ điển hình là cơ sở dữ liệu nơi bạn thực sự lưu trữ tài liệu giấy, ví dụ bằng cách quét thư văn phòng. Dữ liệu là bản PDF được quét và bạn có một số dữ liệu meta luôn tồn tại (được quét tại, được quét bởi, loại tài liệu) và rất nhiều trường siêu dữ liệu có thể tồn tại vào lúc nào đó (số khách hàng, số nhà cung cấp, số đơn đặt hàng, giữ cho đến khi Toàn văn bản OCRed, v.v.). Thông thường bạn không biết trước những trường siêu dữ liệu nào bạn sẽ thêm trong vòng hai năm tới. Những thứ như CouchDB hoạt động tốt hơn nhiều đối với loại dữ liệu đó so với cơ sở dữ liệu quan hệ.
Cá nhân tôi cũng thích thực tế rằng tôi không cần bất kỳ thư viện máy khách nào cho CouchDB ngoại trừ máy khách HTTP, ngày nay được bao gồm trong gần như mọi ngôn ngữ lập trình.
Câu trả lời có lẽ ít rõ ràng nhất: Nếu bạn cảm thấy không đau khi sử dụng RDBMS, hãy ở lại với nó. Nếu bạn luôn phải làm việc xung quanh RDBMS để hoàn thành công việc của mình, cơ sở dữ liệu định hướng tài liệu có thể đáng xem.
Đối với một danh sách chi tiết hơn kiểm tra bài đăng này của Richard Jones .
CouchDB (từ trang web của họ )
Một máy chủ cơ sở dữ liệu tài liệu, có thể truy cập thông qua API JSONful. Nói chung, cơ sở dữ liệu quan hệ không được truy cập đơn giản thông qua các dịch vụ REST, nhưng yêu cầu API SQL phức tạp hơn nhiều. Thông thường các API này (JDBC, ODBC, v.v.) khá phức tạp. REST khá đơn giản.
Đặc biệt và không có lược đồ với không gian địa chỉ phẳng. Cơ sở dữ liệu quan hệ có lược đồ phức tạp, cố định. Bạn xác định bảng, cột, chỉ mục, trình tự, khung nhìn và các thứ khác. Couch không yêu cầu mức độ lập kế hoạch tiên tiến phức tạp, đắt tiền, dễ vỡ này.
Phân phối, có tính năng nhân rộng mạnh mẽ, tăng cường với phát hiện và quản lý xung đột hai chiều. Một số sản phẩm thương mại SQL cung cấp điều này. Do API SQL và các lược đồ cố định, điều này rất phức tạp, khó khăn và tốn kém. Đối với Couch, nó xuất hiện đơn giản và không tốn kém.
Có thể truy vấn và có thể lập chỉ mục, có công cụ báo cáo theo định hướng bảng sử dụng Javascript làm ngôn ngữ truy vấn. SQL và các cơ sở dữ liệu quan hệ cũng vậy. Không có gì mới ở đây.
Vì thế. Tại sao lại là CouchDB?
Để lưu trữ ngu ngốc và phục vụ dữ liệu máy chủ khác.
Trong vài tuần qua, tôi đã chơi với một ứng dụng trực tiếp thăm dò các nguồn cấp dữ liệu của tôi (ngon, flickr, github, twitter ...) và lưu trữ chúng trong couchdb. Cái hay của couchdb là nó cho phép tôi giữ dữ liệu gốc trong cấu trúc ban đầu của nó mà không cần phí. Tôi đã thêm trường 'lớp' vào mỗi tài liệu, lưu trữ máy chủ nguồn và viết một lớp kết xuất javascript cho mỗi nguồn.
Tổng quát hóa, bất cứ khi nào máy chủ của bạn liên lạc với máy chủ khác, lưu trữ không có lược đồ là tốt nhất vì bạn không có quyền kiểm soát lược đồ. Như một phần thưởng, couchdb sử dụng các giao thức gốc của máy chủ và máy khách - JSON để biểu diễn và HTTP REST để vận chuyển.
Phát triển ứng dụng nhanh chóng đến với tâm trí.
Khi tôi liên tục phát triển lược đồ của mình, tôi liên tục thất vọng vì phải duy trì lược đồ trong MySQL / SQLite. Mặc dù tôi chưa làm quá nhiều với CouchDB, nhưng tôi thích việc phát triển lược đồ trong quá trình RAD đơn giản như thế nào.
Một trường hợp mà bạn có thể không muốn sử dụng cơ sở dữ liệu không liên quan là khi bạn có nhiều mối quan hệ nhiều-nhiều; Tôi vẫn chưa hiểu về cách tạo các hàm MapReduce tốt xung quanh các loại mối quan hệ này, đặc biệt nếu bạn cần có siêu dữ liệu trong mối quan hệ tham gia. Tôi không chắc chắn, nhưng tôi không nghĩ các hàm CouchDB Map có thể gọi các truy vấn của riêng họ trên cơ sở dữ liệu, vì điều đó có khả năng gây ra các vòng lặp vô hạn.
Sử dụng cơ sở dữ liệu dựa trên tài liệu khi bạn không cần lưu trữ dữ liệu trong các bảng với các trường có kích thước đồng nhất cho mỗi bản ghi. Thay vào đó, bạn có nhu cầu lưu trữ từng bản ghi dưới dạng tài liệu có một số đặc điểm nhất định. Bất kỳ số lượng trường có độ dài bất kỳ có thể được thêm động vào tài liệu bất cứ lúc nào mà không cần phải "sửa đổi bảng" trước. Các trường trong tài liệu cũng có thể chứa nhiều phần dữ liệu.
Để giải thích về smdelfin: tính linh hoạt. Bạn có thể lưu trữ dữ liệu trong bất kỳ cấu trúc nào (không có cấu trúc và tất cả) và mọi tài liệu có thể hoàn toàn khác nhau. CouchDB đặc biệt hữu ích vì với các chỉ mục "chế độ xem" của họ, bạn có thể lọc ra các tài liệu cụ thể và chỉ truy vấn chế độ xem đó khi bạn muốn các tập hợp con của cơ sở dữ liệu của mình.
Điểm chiến thắng lớn nhất của tôi về cơ sở dữ liệu tài liệu lưu trữ dữ liệu ở định dạng JSON: đây là định dạng gốc cho JavaScript. Do đó, các ứng dụng web JavaScript hoạt động cực kỳ tốt với CouchDB. Gần đây tôi đã tạo một ứng dụng web sử dụng CouchDB và nó rất nhanh trong khi cũng có thể xử lý cấu trúc dữ liệu thay đổi liên tục.
Cơ sở dữ liệu dựa trên tài liệu có lợi thế lớn so với cơ sở dữ liệu quan hệ vì chúng không yêu cầu xác định sơ đồ trả trước - trước khi có thể nhập bất kỳ dữ liệu nào.
Ngoài ra, bạn nên sử dụng cơ sở dữ liệu tài liệu nếu dữ liệu của bạn không liên quan và không thể được lưu trữ trong bảng mà thay vào đó là một tập hợp các hình ảnh, hoặc ví dụ như các bài báo.
Một lợi thế khác là sự dễ dàng sử dụng cơ sở dữ liệu dựa trên tài liệu trong phát triển web. Để biết thêm chi tiết về các mô hình cơ sở dữ liệu NoQuery, hãy kiểm tra nguồn này: https://arxiv.org/ftp/arxiv/ con / 1/99 / 1509.08035.pdf