Các trường hợp sử dụng NoQuery [đã đóng]

Tôi đang phát triển một ứng dụng cho hội thảo nghiên cứu sinh viên đại học của tôi xung quanh ý tưởng về sự kiên trì polyglot. Tôi đã đọc cuốn sách của Martin Fowlers và thực hiện một số nghiên cứu trực tuyến khác về các loại khác nhau của NoQuery db. Tôi tò mò không biết các trường hợp sử dụng khác nhau dành cho các cơ sở dữ liệu NoQuery khác nhau là gì?

Hiện tại tôi có những gì Fowler đã chỉ ra (nghiên cứu khác chủ yếu được thực hiện trong API).

Giá trị cốt lõi:

• dữ liệu phiên
• Thông tin người dùng
• giỏ hàng
• về cơ bản bất cứ thứ gì có một khóa duy nhất có thể dễ dàng tạo và nhân rộng

Tài liệu:

• đăng nhập sự kiện
• CMS / viết blog
• thương mại điện tử (sau khi giao dịch đã hoàn thành)
• phân tích trang web

Cột họ:

• đăng nhập sự kiện
• CMS / viết blog
• quầy
• hết hạn sử dụng

Biểu đồ:

• dữ liệu được kết nối
• dịch vụ dựa trên địa điểm
• công cụ đề xuất

Vì vậy, những trường hợp sử dụng khác là gì? Cụ thể hơn các trường hợp sử dụng cho từng loại NoQuery db tốt hơn mô hình quan hệ là gì?

Một danh sách rất lớn các trường hợp sử dụng NoQuery

Danh sách đó có ích ngay bây giờ và sau đó, và cũng chỉ ra khi một giải pháp NoQuery nào đó chuyên biệt cho trường hợp sử dụng cụ thể đó. Chủ đề HackerNews ban đầu (được liên kết ở dưới cùng của trang đó) cũng hữu ích cho bình luận mở rộng.

Tôi nghĩ rằng bạn đã bao gồm hầu hết mọi thứ. Tôi có thể cung cấp cho bạn thêm về cơ sở dữ liệu đồ thị Tôi đã thấy mọi người hoặc nhà nghiên cứu sử dụng cơ sở dữ liệu đồ thị để phân tích ngữ nghĩa hoặc lưu trữ bản thể luận cho Xử lý ngôn ngữ tự nhiên.

Và vì tôi đã sử dụng rất nhiều Graph db, tôi nghĩ những gì Graph db cung cấp nhiều hơn so với mô hình quan hệ có thể cung cấp. Ví dụ: nếu tôi có một ứng dụng web và tôi để kết nối tất cả bạn bè của mình từ Facebook và Twitter dựa trên vị trí hoặc sở thích. Tôi có thể làm điều đó trong một truy vấn. Tuy nhiên, bạn cũng có thể làm điều đó trong SQL nếu bạn thực sự muốn, nhưng SQL có thể dài A4 hoặc hơn thế nếu bạn muốn làm đúng.

Tại sao không đi về điều này nhiều hơn? Ví dụ: tại sao "CMS / blog" phù hợp hơn với cơ sở dữ liệu tài liệu (hoặc bất cứ điều gì)? Các đặc tính chung của các ứng dụng này khiến bạn nghĩ rằng chúng phù hợp hơn với công nghệ này hay công nghệ khác là gì?

Hãy xem xét các điểm mạnh của từng công nghệ DBMS và trên thực tế, lý thuyết mà mỗi người dựa trên. Họ thực hiện mô hình dữ liệu nào? (Mỗi người trong thực tế có một mô hình dữ liệu không?) Các thuộc tính của từng mô hình dữ liệu là gì và làm thế nào để các thuộc tính của ánh xạ ứng dụng lên các mô hình dữ liệu? Nếu bạn phát triển một bản đồ như vậy, bạn sẽ có cách mô tả bất kỳ ứng dụng nào , ngay cả một ứng dụng bạn chưa từng nghe đến hoặc chưa được phát minh.

Codd định nghĩa một mô hình dữ liệu bao gồm ba tính năng lồng vào nhau: cấu trúc, hoạt động và các ràng buộc. Các mô hình quan hệ có tất cả ba trong thuổng. Nếu bạn nhìn kỹ vào các lựa chọn thay thế, bạn sẽ thấy họ thiếu ít nhất một và thường là hai trong số đó. Bất kỳ công nghệ không dựa trên mô hình quan hệ là ipso facto ít chức năng. Vì lý do đó, có thể nói rằng mọi ứng dụng đều có thể được hỗ trợ cho mô hình quan hệ (nếu không phải bởi các sản phẩm quan hệ còn tồn tại). Mô hình quan hệ vẫn được phát triển đầy đủ hơn, mạnh mẽ hơn và đơn giản hơn bất kỳ mô hình nào khác đã nghĩ ra. Sẽ khó để cải thiện vì nó dựa trên logic vị ngữ và lý thuyết tập hợp.

Có lẽ bạn có thể xác định các ứng dụng mà theo đó, các hoạt động được xác định rõ không quan trọng. Nhưng bạn muốn chắc chắn rằng trước tiên bạn hiểu lý do tại sao chúng quan trọng trước khi bạn có thể nói chắc chắn tại sao chúng không cần thiết (hoặc thậm chí chỉ hữu ích) cho một ứng dụng cụ thể.

Sớm hay muộn, ai đó sẽ nói với bạn "quy mô không quan hệ" và công nghệ X rất nhanh. Khi họ làm điều đó, hãy nhớ rằng họ đã từ bỏ các tính năng mà công nghệ X thiếu so với mô hình quan hệ, các tính năng có thể rất quan trọng. Ngoài ra, một mô hình dữ liệu không nhanh hay chậm, chỉ có một triển khai. Bất cứ khi nào có nhiều lập trình viên hơn máy móc, mua phần cứng nhanh hơn sẽ rẻ hơn so với thuê nhiều lập trình viên.