query - mongodb tutorial
Buenas prácticas de NoSQL (2)
¿Cuáles son las mejores prácticas para bases de datos NoSQL, OODB o cualesquiera otros acrónimos que puedan existir para ellos?
Por ejemplo, a menudo he visto un campo "tipo" que se usa para decidir cómo el documento de la base de datos (en términos de couchDB / mongoDB) debe ser interpretado por el cliente, la aplicación.
Donde corresponda, use PHP como un idioma de referencia. Leer: también me interesa saber cómo se pueden manejar mejor estos datos en el lado del cliente, no solo estrictamente la estructura de la base de datos. Esto significa prácticamente que también estoy buscando patrones como "ORM" para DB de SQL (registro activo, mapeador de datos, etc.).
No dude en hacer declaraciones sobre cómo un DB así y las nuevas características de PHP 5.3 pueden funcionar mejor juntas.
Creo que actualmente, la idea general de los almacenes de datos NoSQL y el concepto de bases de datos de documentos es tan nueva y diferente de las ideas establecidas que impulsan el almacenamiento relacional, que actualmente existen muy pocas (si las hay) mejores prácticas.
Sabemos en este punto que las reglas para almacenar sus datos dentro de, por ejemplo, CouchDB (o cualquier otra base de datos de documentos) son bastante diferentes a las de una relación. Por ejemplo, es casi un hecho que la normalización y el objetivo de 3NF no es algo que uno debería esforzarse. Uno de los ejemplos comunes sería el de un blog simple.
En una tienda relacional, tendrías una tabla para "Publicaciones", "Comentarios" y "Autores". Cada autor tendría muchas publicaciones, y cada publicación tendría muchos comentarios. Este es un modelo que funciona bastante bien y se correlaciona bien con cualquier DB relacional. Sin embargo, almacenar los mismos datos dentro de un docDB probablemente sería bastante diferente. Probablemente tendrías algo así como una colección de documentos Post, cada uno de los cuales tendría su propio Autor y una colección de Comentarios integrados. Por supuesto, esa no es la única forma en que podrías hacerlo, y es un compromiso (ahora solicitar una sola publicación es rápido; solo se realiza una operación y se recupera todo), pero no se puede mantener la relación entre los autores y las publicaciones (ya que todo se convierte en parte del documento posterior).
También he visto ejemplos que hacen uso de un atributo "tipo" (en un ejemplo de CouchDB). Claro, eso suena como un enfoque viable. ¿Es el mejor? No tengo ni idea. Ciertamente, en MongoDB utilizaría colecciones independientes dentro de una base de datos, lo que haría que el atributo de tipo no tenga sentido. En CouchDB ... tal vez eso sea lo mejor. ¿Las otras alternativas? ¿Bases de datos separadas para cada tipo de documento? Esto parece un poco raro, así que me incliné hacia la solución de "tipo". Pero solo soy yo. Tal vez hay algo mejor.
Me doy cuenta de que he hablado un poco aquí y he dicho muy poco, muy probablemente nada que no supieras. Sin embargo, mi punto es este: creo que nos corresponde a nosotros experimentar con las herramientas que tenemos y los datos con los que estamos trabajando y con el tiempo las buenas ideas se difundirán y se convertirán en las mejores prácticas. Creo que estás preguntando demasiado temprano en el juego.
"NoSQL" debería ser más sobre construir el almacén de datos para seguir los requisitos de su aplicación, no sobre construir la aplicación para seguir una cierta estructura, eso es más como un enfoque SQL tradicional.
No abandone una base de datos relacional "solo porque"; solo hazlo si tu aplicación realmente lo necesita.