qué base de datos se adapta a mi aplicación mysql o mongodb? usando Node.js, Backbone, Now.js

Question

Quiero hacer una aplicación como docs.google.com (sin su API, completamente en mi propio servidor) usando frontend: columna vertebral backend: nodo

Qué base de datos ¿pensarías que es mejor? ¿mysql o mongodb? Debería soportar una buena escalabilidad. Estoy familiarizado con mysql con php y estaré contento si la respuesta es mysql. Pero vi muchos tutoriales, usaron mongodb, ¿por qué usaron mongodb sin mysql? ¿Qué debo usar?

¿Alguien me puede dar un enlace para alguna aplicación de ejemplo (con fuente) construir usando red troncal, Node, mysql (o mongo). o al menos aplicación con el Nodo y mysql

Gracias

Answer 1

Con MongoDB, sólo puede tienda de objetos JSON y recuperarlos completamente formados, por lo que realmente no necesita una capa ORM y que pase menos tiempo de CPU traducir sus datos de ida y vuelta. Los desarrolladores detrás de MongoDB también han hecho que la escala horizontal de la base de datos sea una prioridad más alta y le permiten ejecutar código Javascript arbitrario para preprocesar datos en el lado de la base de datos (lo que permite el filtrado de datos de estilo map-reduce).

Pero pierde algunas de estas ganancias: No puede unir registros. En realidad, la estructura JSON que almacena solo puede realizarse a través de combinaciones en SQL, pero en MongoDB solo tiene esa estructura para sus datos, mientras que en SQL puede hacer consultas de forma diferente y obtener sus datos representados de maneras alternativas mucho más fácil, por lo que necesita hacer muchos análisis en su base de datos, MongoDB lo hará más difícil.

El lenguaje de consulta en MongoDB es "más áspero", en mi opinión, que SQL, en parte porque es menos familiar, y en parte porque las características de consulta se "sienten" al azar, en parte para hacerlo JSON válido y en parte porque hay literalmente un par de formas de hacer lo mismo, y algunas son formas antiguas que no son tan útiles o tienen un formato regular como las demás. Y existe la complejidad añadida de los tipos de matriz y subobjeto sobre el diseño simple basado en filas de SQL, por lo que la sintaxis debe poder consultar las matrices que contienen algunos de los valores que ha definido, contienen todos del los valores que ha definido, contienen solo los valores que ha definido y contienen ninguno de los valores que ha definido. Las mismas distinciones se aplican a las claves de objeto y sus valores, y esto hace que la sintaxis de la consulta sea más difícil de comprender. (Y aunque puedo ver la necesidad de edge-cases, el parámetro de consulta $where, que toma una función javascript que se ejecuta en cada registro de los datos y devuelve un booleano, es una canción de Siren porque puedes definir fácilmente qué objetos quieres para volver o no, pero tiene que ejecutar en cada registro en la base de datos, no hay índices se pueden utilizar.)

por lo tanto, depende de lo que quiere hacer, pero ya que usted dice que es un Google Docs clon, que probablemente no se preocupan por cualquier representación pero la representación de documentos, en sí, y que está probablemente sólo va a consulta basada en ID de documento, nombre del documento o del propietario del nombre/ID, nada demasiado complejo en la consulta.

Entonces, yo diría que es capaz de tomar la representación JSON del documento que su usuario está editando, y simplemente ponerlo en la base de datos y hacer que indexe automáticamente estos campos importantes, vale la pena el precio de aprender una nueva base de datos .

Answer 2

David proporcionó una buena respuesta. Algunas cosas para agregar a eso.

1. La naturaleza flexible de MongoDB permite un desarrollo fácil ágil/iterativo.
2. MongoDB como node.js es de naturaleza asíncrona y funciona muy bien en entornos asincronos.
3. Mongoose es un buen ODM (mapeador de documentos de objeto) que hace que trabajar con MongoDB con Node.js sea muy natural. A diferencia de los ORM, esta es una capa muy delgada.

Para la funcionalidad de Google Doc, la flexibilidad de la estructura de datos & proporcionada por MongoDB se siente como un ajuste mucho mejor.

Puede encontrar buenas publicaciones de ejemplo buscando mongoose, node y MongoDB.

Aquí hay una que también utiliza Backbone.js y se ve bien http://mattkopala.com/blog/2012/02/12/getting-started-with-nodejs/

Answer 3

también estaba luchando con esta elección mirando el bombo creado usando MongoDB para tareas que no fue construido para. Así que mis 2 centavos son:

1. almacenar y recuperar objetos jerárquicos, que sus documentos son probablemente, es más fácil en MongoDB, como dice David. Sin embargo, se vuelve más complicado si desea almacenar documentos que son más grandes que 16Mb, la respuesta de MongoDB es GridFS.

2. Organizar documentos en carpetas, grupos, hacer un seguimiento de qué usuario posee qué documentos y quién ha proporcionado acceso a ellos es definitivamente más fácil con MySQL; tiene la ventaja de poderosas consultas SQL con combinaciones, etc. EXPLICAR la optimización, desencadenadores, funciones, procedimientos almacenados, etc. MongoDB no está cerca.

Entonces, ¿qué le impide utilizar tanto MySQL para organizar los documentos y MongoDB para almacenar una colección de documentos identificados por id (o varias colecciones - uno para cada tipo de documento)? Me parece que la mejor opción y el uso de dos bases de datos en una aplicación no es un problema, realmente.

MySQL almacenará usuarios, grupos, carpetas, permisos, lo que sea que desee, y para cada documento guardará una referencia a la colección y la identificación del documento (MongoDB tiene un formato especial para ella - DBRefs). MongoDB almacenará los documentos en colecciones, si son todos menores de 16 MB, o las vistas previas y los metadatos de los documentos en las colecciones y los documentos completos en GridFS.