Đối số cho lựa chọn sử dụng: RavenDB vs SQL Server - hiệu suất, độ tin cậy và đơn giản

Question

Điểm nào cần được xem xét, trong khi chọn lớp dữ liệu cho ứng dụng web?

Có lựa chọn nào thích hợp hơn để sử dụng cơ sở dữ liệu tài liệu trên cơ sở dữ liệu quan hệ, trong khi phát triển dự án nhỏ trên tải trọng lớn và nặng hoặc ngược lại?

Loại cấu trúc cơ sở dữ liệu nào được ưu tiên cho các phương pháp này - nếu tôi có cơ sở dữ liệu đơn giản mà không có quá nhiều quan hệ, tốt hơn là sử dụng một cách tiếp cận khác?

Answer 1

Kể từ khi câu hỏi này được mời bình luận cá nhân, đây là quan điểm của tôi :

SQL Server không phải là một cơ sở dữ liệu để lưu trữ bất cứ điều gì ngoại trừ dữ liệu báo cáo ad-hoc. Thật tuyệt vời cho điều đó, các báo cáo đặc biệt, khai thác dữ liệu, khám phá mối quan hệ thời gian thực - và tối ưu cho các ứng dụng này vì cách quay lại khi Codd thiết kế các quy tắc, đó là những gì nó được thiết kế cho (xem Data Driven Conspiracy để biết thêm chi tiết)

Tất nhiên bạn có thể lưu trữ các loại dữ liệu khác trong cơ sở dữ liệu quan hệ. Ví dụ bạn có thể nối tiếp trạng thái miền của bạn với cơ sở dữ liệu SQL Server và truy xuất trạng thái đó vào một ngày sau đó nhưng đây là một sử dụng khủng khiếp của một hệ thống quan hệ. Thật tệ, trên thực tế, toàn bộ các lớp mã (được gọi là 'lớp dữ liệu' hoặc DAL), có hàng nghìn dòng, được yêu cầu để làm cho loại công việc này từ xa có khả năng, có thể kiểm tra, bảo trì được. Bí quyết tự tin lâu dài, tuyệt vời dành cho các nhà bán lẻ dựa trên SQL để thuyết phục chúng tôi rằng không có cách nào tốt hơn để lưu trữ dữ liệu phân cấp/tài liệu ngoài chuyển đổi thời gian thực giữa các cấu trúc dữ liệu hoàn toàn khác nhau. DAL và ORM mới nhất đều đã được đánh giá cao nhưng cuối cùng, chúng không có gì khác ngoài các codec để tách các bit của bạn qua lại giữa các tổ chức dữ liệu khác nhau - các mẫu khác nhau trên đĩa.

Sự điên rồ!

Vì vậy, hãy quên đi tất cả các đối số của bity, thiên hà-trên-pinhead về nguyên tử, tính nhất quán, cách ly, độ bền. Con voi trong phòng là nếu bạn đang sử dụng SQL Server và bạn không phải là công ty dược đang khai thác dữ liệu tự động cho các suy luận ẩn trong các quần thể lớn (bạn?) Thì có thể bạn đang sử dụng công nghệ sai để lưu trữ dữ liệu của mình .

Nếu, mặt khác, bạn là nhà phát triển ứng dụng khiêm tốn - một nhà lập trình, giống như hầu hết chúng ta, chỉ muốn tuần tự hóa trạng thái tên miền theo cách không có nghĩa là học tập toàn bộ hệ tư tưởng và cú pháp mới sau đó, vì lợi ích tốt lành, không sử dụng một cơ sở dữ liệu quan hệ. Chỉ cần không.

RavenDB? Tôi đã sử dụng điều này một thời gian (đã phát triển thông qua DB4O và CouchBase) và tôi có thể nói rằng nó làm những gì nó nói trên tin. Nó lưu trữ nội dung của tôi và trả lại cho tôi khi tôi hỏi. Tôi không phải viết bất kỳ lớp dữ liệu nào cũng như không sử dụng ORM của bên thứ ba. Tôi không phải học một ngôn ngữ truy vấn có cấu trúc và tôi không phải sử dụng các tính năng bổ sung để làm cho công việc tìm kiếm toàn văn bản (RavenDB dựa trên Lucene vì vậy tất cả chỉ hoạt động). Càng xa càng tốt.

Nhưng thực sự, có vấn đề gì bạn sử dụng miễn là nó, cho công việc trong tay, dễ dàng để mã, nhanh chóng và hiệu quả? Đối với phát triển ứng dụng bình thường RavenDB là tất cả những thứ này trong khi SQL Server thì không. Điều đó không có nghĩa là các DB quan hệ là xấu - đừng đổ lỗi cho nạn nhân - Tôi hoàn toàn thừa nhận rằng đối với một số phát triển chuyên biệt nhất định, bạn thực sự có thể cần thêm một chút nữa ... kỳ lạ, một kho dữ liệu quan hệ như vậy.

Nhưng trong trường hợp bạn vẫn đang bám vào đống đổ nát, bạn cần phải tự hỏi mình: Nếu chúng ta sử dụng các kho dữ liệu đơn giản, nhanh chóng, thanh lịch để đáp ứng nhu cầu của chúng tôi với tư cách là nhà phát triển ứng dụng. mảnh thúc giục bạn áp dụng SQL Server sau đó bạn sẽ rất có thể cười tôi hay thương hại tôi. Một điều chắc chắn - bạn sẽ không trao đổi với SQL Server. Vì vậy, chúng tôi chứng minh rằng quán tính một mình là lực lượng hướng dẫn mà giữ SQL Server tacked vào dòng chính. Quán tính và vô minh. Quán tính, sự thiếu hiểu biết và tham lam của công ty ....