cơ sở dữ liệu nào phù hợp với mysql ứng dụng của tôi hoặc mongodb? sử dụng Node.js, Backbone, Now.js

Question

Tôi muốn làm một ứng dụng như docs.google.com (không api của nó, hoàn toàn trên máy chủ của riêng tôi) sử dụng frontend: xương sống backend: nút

cơ sở dữ liệu gì bạn có nghĩ là tốt hơn không? mysql hoặc mongodb? Nên hỗ trợ khả năng mở rộng tốt. Tôi quen thuộc với mysql với php và tôi sẽ rất vui nếu câu trả lời là mysql. Nhưng nhiều hướng dẫn tôi thấy, họ sử dụng mongodb, tại sao họ sử dụng mongodb mà không có mysql? Tôi nên sử dụng cái gì?

Bất cứ ai có thể cho tôi liên kết cho một số ứng dụng mẫu (với nguồn) xây dựng bằng cách sử dụng xương sống, Node, mysql (hoặc mongo). hoặc ứng dụng ít nhất. với Node và mysql

Cảm ơn

Answer 1

Với MongoDB, bạn có thể chỉ cửa hàng đối tượng JSON và lấy chúng hoàn toàn hình thành, do đó bạn không thực sự cần một lớp ORM và bạn dành ít thời gian CPU dịch dữ liệu của bạn qua lại. Các nhà phát triển phía sau MongoDB cũng đã thực hiện mở rộng quy mô theo chiều ngang cơ sở dữ liệu một ưu tiên cao hơn và cho phép bạn chạy mã Javascript tùy ý để xử lý trước dữ liệu ở phía DB (cho phép lọc kiểu dữ liệu bản đồ).

Nhưng bạn mất một số lợi ích này: Bạn không thể tham gia hồ sơ. Trên thực tế, cấu trúc JSON bạn lưu trữ chỉ có thể được thực hiện thông qua các kết nối trong SQL, nhưng trong MongoDB bạn chỉ có một cấu trúc cho dữ liệu của mình, trong khi trong SQL bạn có thể truy vấn khác nhau và dữ liệu của bạn được biểu diễn theo nhiều cách khác nhau dễ dàng hơn. cần phải làm rất nhiều phân tích trên cơ sở dữ liệu của bạn, MongoDB sẽ làm cho khó hơn. Ngôn ngữ truy vấn trong MongoDB là "khó khăn hơn", theo ý kiến ​​của tôi, hơn SQL, một phần vì nó ít quen thuộc hơn, và một phần vì các tính năng truy vấn "cảm thấy" được đặt một cách lộn xộn, một phần để làm cho nó hợp lệ JSON, và một phần vì có nghĩa đen là một vài cách để làm điều tương tự, và một số là những cách cũ hơn mà không phải là hữu ích hoặc định dạng thường xuyên như những người khác. Và có thêm sự phức tạp của mảng và các loại đối tượng phụ trên thiết kế dựa trên hàng đơn giản của SQL, do đó cú pháp phải có khả năng xử lý truy vấn cho các mảng chứa một số giá trị bạn đã xác định, chứa tất cả của giá trị bạn đã xác định, chỉ chứa chỉ giá trị bạn đã xác định và chứa không có giá trị bạn đã xác định. Sự phân biệt giống nhau áp dụng cho các khóa đối tượng và giá trị của chúng, và điều này làm cho cú pháp truy vấn khó nắm bắt hơn. (Và trong khi tôi có thể thấy nhu cầu về các trường hợp cạnh, tham số truy vấn $where, có chức năng javascript chạy trên mọi bản ghi dữ liệu và trả về boolean, là một bài hát Siren vì bạn có thể dễ dàng xác định đối tượng bạn muốn để trả lại hay không, nhưng nó phải chạy trên mỗi bản ghi trong cơ sở dữ liệu, không có chỉ mục nào có thể được sử dụng.)

Vì vậy, nó phụ thuộc vào những gì bạn muốn làm, nhưng vì bạn nói nó là dành cho Google Documents clone, bạn có lẽ không quan tâm đến bất kỳ đại diện nào nhưng bản trình bày tài liệu, chính bạn và có thể là chỉ truy vấn dựa trên ID tài liệu, tên tài liệu hoặc ID/tên của chủ sở hữu phức tạp trong truy vấn. Sau đó, tôi muốn nói là có thể lấy biểu diễn JSON của tài liệu mà người dùng của bạn đang chỉnh sửa và chỉ cần ném nó vào cơ sở dữ liệu và tự động lập chỉ mục các trường quan trọng này, đáng giá của việc học một cơ sở dữ liệu mới. .

Answer 2

David cung cấp câu trả lời hay. Một vài điều cần thêm vào nó.

1. Bản chất linh hoạt của MongoDB cho phép phát triển nhanh/dễ phát triển.
2. MongoDB như node.js không đồng bộ về bản chất và hoạt động rất tốt trong môi trường không đồng bộ.
3. Mongoose là một ODM tốt (đối tượng tài liệu mapper) mà làm việc với MongoDB với Node.js cảm thấy rất tự nhiên. Không giống như ORMs, đây là một lớp rất mỏng.

Đối với chức năng của Google Doc, tính linh hoạt & cấu trúc dữ liệu rất phong phú do MongoDB cung cấp có vẻ phù hợp hơn nhiều.

Bạn có thể tìm thấy một số bài đăng mẫu tốt bằng cách tìm kiếm mongoose, nút và MongoDB.

Dưới đây là một trong đó cũng sử dụng backbone.js và có vẻ tốt http://mattkopala.com/blog/2012/02/12/getting-started-with-nodejs/

Answer 3

Tôi cũng đã phải vật lộn với sự lựa chọn này nhìn vào hype tạo bằng cách sử dụng MongoDB cho các nhiệm vụ đó không được xây dựng cho. Vì vậy, 2 xu của tôi là:

Lưu trữ và truy xuất các đối tượng thứ bậc, có thể dễ dàng hơn trong MongoDB, như David nói. Nó trở nên phức tạp hơn nếu bạn muốn lưu trữ các tài liệu lớn hơn 16Mb - Câu trả lời của MongoDB là GridFS.

1. Sắp xếp tài liệu trong thư mục, nhóm, theo dõi người dùng nào sở hữu tài liệu và người được cung cấp quyền truy cập vào họ chắc chắn dễ dàng hơn với MySQL - bạn có lợi thế về truy vấn SQL mạnh mẽ với kết nối, v.v. GIẢI THÍCH tối ưu hóa, kích hoạt, chức năng, thủ tục lưu trữ, vv MongoDB là hư không gần.

Vì vậy, điều gì ngăn bạn sử dụng cả MySQL để sắp xếp tài liệu và MongoDB lưu trữ một bộ sưu tập tài liệu được xác định bởi id (hoặc nhiều bộ sưu tập - một cho mỗi loại tài liệu)? Dường như với tôi sự lựa chọn tốt nhất và sử dụng hai cơ sở dữ liệu trong một ứng dụng không phải là một vấn đề, thực sự.

MySQL sẽ lưu trữ người dùng, nhóm, thư mục, quyền - bất kỳ thứ gì bạn ưa thích - và cho mỗi tài liệu, nó sẽ lưu trữ tham chiếu đến tập hợp và id tài liệu (MongoDB có định dạng đặc biệt cho nó - DBRef). MongoDB sẽ lưu trữ tài liệu trong bộ sưu tập, nếu chúng nhỏ hơn 16MB hoặc xem trước và siêu dữ liệu của các tài liệu trong bộ sưu tập và toàn bộ tài liệu trong GridFS.