Cómo dejar de pensar "relacionalmente"

Question

En el trabajo, recientemente comenzamos un proyecto utilizando CouchDB (una base de datos orientada a documentos). He estado teniendo dificultades para desaprender todos mis conocimientos de DB relacionales.

Me preguntaba cómo algunos de ustedes superaron este obstáculo? Cómo dejaste de pensar relacionalmente y comenzaste a pensar documentalmente (me disculpo por inventar esa palabra).

¿Alguna sugerencia? ¿Consejos útiles?

Editar: Si hace alguna diferencia, estamos usando Ruby & CouchPotato para conectarse a la base de datos.

Editar 2: SO me molestaba para aceptar una respuesta. Elegí la que me ayudó a aprender más, creo. Sin embargo, no hay una respuesta "correcta" real, supongo.

Answer 1

Creo que, después de leer un par de páginas sobre este tema, todo depende de los tipos de datos con los que se trate.

RDBMSes representan un enfoque de arriba hacia abajo, donde usted, el diseñador de la base de datos, afirma la estructura de todos los datos que existirán en la base de datos. Usted define que una Persona tiene un Primero, Último, Segundo Nombre y una Dirección de Casa, etc. Puede hacer cumplir esto usando un RDBMS. Si no tiene una columna para el HomePlanet de una persona, mala suerte, quiere ser una persona que tenga un HomePlanet diferente de la Tierra; tendrá que agregar una columna en una fecha posterior o los datos no se pueden almacenar en el RDBMS. La mayoría de los programadores hacen suposiciones como esta en sus aplicaciones de todos modos, así que esto no es una tontería para asumir y hacer cumplir. Definir cosas puede ser bueno. Pero si necesita registrar atributos adicionales en el futuro, deberá agregarlos. El modelo de relación asume que sus atributos de datos no cambiarán mucho.

Bases de datos de tipo "nube" que utilizan algo parecido a MapReduce, en su caso CouchDB, no hacen la suposición anterior, y en su lugar miran los datos de abajo hacia arriba. Los datos se ingresan en documentos, que pueden tener cualquier cantidad de atributos variables. Asume que sus datos, por definición propia, son diversos en los tipos de atributos que podría tener. Dice: "Solo sé que tengo este documento en la base de datos Persona que tiene un atributo HomePlanet de" Eternium "y un Nombre de" Lord Nibbler "pero no LastName". Este modelo se adapta a las páginas web: todas las páginas web son un documento, pero los contenidos/etiquetas/claves reales del documento varían tanto que no se pueden ajustar a la estructura rígida en la que el DBMS se pontifica desde lo alto. Esta es la razón por la cual Google piensa que el modelo MapReduce roxors soxors, porque el conjunto de datos de Google es tan diverso que necesita construir para la ambigüedad desde el principio, y debido a los conjuntos de datos masivos pueden utilizar el procesamiento paralelo (que MapReduce hace trivial) . El modelo de base de datos de documentos asume que los atributos de sus datos pueden/cambiarán mucho o serán muy diversos con "lagunas" y muchas columnas escasamente pobladas que uno podría encontrar si los datos estuvieran almacenados en una base de datos relacional. Si bien podría usar un RDBMS para almacenar datos como este, se pondría muy rápido.

Para responder a su pregunta, entonces: no puede pensar "relacionalmente" en absoluto al buscar en una base de datos que utiliza el paradigma MapReduce. Porque, en realidad, no tiene una relación forzada. Es una joroba conceptual que tendrás que superar.

---

Un buen artículo me encontré con que se comparan y contrastan las dos bases de datos bastante bien es MapReduce: A Major Step Back, que sostiene que las bases de datos de paradigma MapReduce son un paso tecnológico hacia atrás, y son inferiores a RDBMSes. Tengo que estar en desacuerdo con la tesis del autor y presentaría que el diseñador de la base de datos simplemente tendría que seleccionar el más adecuado para su situación.

Answer 2

puede ser usted debe leer este http://books.couchdb.org/relax/getting-started

Yo mismo acabo de oído y es interesante, pero no tienen idea de cómo implementar que en la aplicación en el mundo real;)

Answer 3

Una cosa que puedes intentar es obtener una copia de firefox y firebug, y jugar con el map y reducir las funciones en javascript. en realidad son bastante fresco y divertido, y parecen ser la base de la forma de hacer las cosas de CouchDB

aquí es pequeño artículo de Joel sobre el tema: http://www.joelonsoftware.com/items/2006/08/01.html

Answer 4

Se trata de los datos. Si tiene datos que tienen más sentido relacional, una tienda de documentos puede no ser útil. Un sistema típico basado en documentos es un servidor de búsqueda, tiene un gran conjunto de datos y desea encontrar un elemento/documento específico, el documento es estático o tiene una versión.

En una situación de tipo de archivo, los documentos pueden ser literalmente documentos, que no cambian y tienen estructuras muy flexibles. No tiene sentido almacenar sus metadatos en bases de datos relacionales, ya que son muy diferentes, por lo que muy pocos documentos pueden compartir esas etiquetas. Los sistemas basados ​​en documentos no almacenan valores nulos.

Datos no relacionales/documentales tienen sentido cuando se desnormalizan. No cambia mucho o no te importa tanto la consistencia.

Si su caso de uso se adapta bien a un modelo relacional, probablemente no valga la pena exprimirlo en un modelo de documento.

Aquí hay un buen artículo sobre non relational databases.

Otra forma de pensar es que un documento es una fila. Todo sobre un documento está en esa fila y es específico para ese documento. Las filas son fáciles de dividir, por lo que escalar es más fácil.

Answer 5

En CouchDB, como Lotus Notes, realmente no debería pensar en un documento como análogo a una fila.

En su lugar, un documento es una relación (tabla).

Cada documento tiene un número de filas - los valores de campo:

ValueID(PK) Document ID(FK) Field Name  Field Value 
======================================================== 
92834756293 MyDocument  First Name  Richard 
92834756294 MyDocument  States Lived In TX 
92834756295 MyDocument  States Lived In KY 

Cada View es una consulta de referencias cruzadas que selecciona a través de una masiva UNION ALL de cada documento.

Por lo tanto, sigue siendo relacional, pero no en el sentido más intuitivo, y no en el sentido que más importa: buenas prácticas de administración de datos.

Answer 6

Las bases de datos orientadas a documentos no rechazan el concepto de relaciones, simplemente dejan que las aplicaciones desreferencian los enlaces (CouchDB) o incluso tienen soporte directo para las relaciones entre documentos (MongoDB). Lo que es más importante es que los DODB son sin esquema. En los almacenamientos basados ​​en tablas, esta propiedad se puede lograr con una sobrecarga considerable (vea la respuesta de richardtallent), pero aquí se hace de manera más eficiente. Lo que realmente deberíamos aprender cuando pasamos de un RDBMS a un DODB es olvidarnos de las tablas y comenzar a pensar en los datos. Eso es lo que el estimulador de ovejas llama el enfoque de "abajo hacia arriba".Es un esquema en constante evolución, no un lecho de Procrustean predefinido. Por supuesto, esto no significa que los esquemas deberían abandonarse por completo de ninguna forma. Su aplicación debe interpretar los datos, de alguna manera limitar su forma, esto se puede hacer organizando documentos en colecciones, haciendo modelos con métodos de validación, pero este es ahora el trabajo de la aplicación.