Cómo dejar de pensar & # 8220; relacionalmente & # 8221;

Question

En el trabajo, recientemente comenzamos un proyecto usando CouchDB (una base de datos orientada a documentos). He estado teniendo dificultades para desaprender todo mi conocimiento relacional de db.

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

¿Alguna sugerencia? Consejos útiles?

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

Editar 2 : SO me estaba molestando para que aceptara una respuesta. Elegí el que más me ayudó a aprender, creo. Sin embargo, no hay un verdadero "correcto" respuesta, supongo.

Answer 1

Creo que, después de leer detenidamente en un par de páginas sobre este tema, todo depende de los tipos de datos con los que está tratando.

Los RDBMS 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 nombre, apellido, segundo nombre y una dirección particular, etc. Puede aplicar esto utilizando un RDBMS. Si no tiene una columna para el HomePlanet de una persona, mala suerte quiere ser una persona que tenga un HomePlanet diferente al de la Tierra; deberá agregar una columna más adelante o los datos no podrán almacenarse en el RDBMS. De todos modos, la mayoría de los programadores hacen suposiciones como esta en sus aplicaciones, por lo que no es una tontería 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 supone que sus atributos de datos no cambiarán mucho.

" Nube " escriba bases de datos utilizando algo como MapReduce, en su caso CouchDB, no haga la suposición anterior y, en su lugar, mire los datos de abajo hacia arriba. Los datos se ingresan en documentos, que pueden tener cualquier número de atributos variables. Se supone que sus datos, por su propia definición, 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 sin apellido. " Este modelo se ajusta 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 puede encajarlos en la estructura rígida que el DBMS certifica desde arriba. Esta es la razón por la que Google cree que el modelo MapReduce roxors soxors, porque el conjunto de datos de Google es tan diverso que necesita incorporarse para la ambigüedad desde el primer momento, y debido a los conjuntos de datos masivos poder utilizar el procesamiento paralelo (que MapReduce hace trivial) . El modelo de base de datos de documentos supone 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 se almacenaran en una base de datos relacional. Si bien podría usar un RDBMS para almacenar datos como este, se pondría feo muy rápido.

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

---

Un buen artículo que encontré que compara y contrasta bastante bien las dos bases de datos es MapReduce: Un paso importante hacia atrás , que argumenta que las bases de datos del paradigma MapReduce son un paso tecnológico hacia atrás y son inferiores a los RDBMS. Tengo que estar en desacuerdo con la tesis del autor y afirmaría que el diseñador de la base de datos simplemente tendría que seleccionar el adecuado para su situación.

Answer 2

Se trata de los datos. Si tiene datos que tienen más sentido relacionalmente, un almacén de documentos puede no ser útil. Un sistema basado en documentos típico 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 está versionado.

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 todos son muy diferentes, por lo que muy pocos documentos pueden compartir esas etiquetas. Los sistemas basados ??en documentos no almacenan valores nulos.

Los datos no relacionales / tipo documento tienen sentido cuando se desnormalizan. No cambia mucho o no le importa mucho la consistencia.

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

Aquí hay un buen artículo sobre bases de datos no relacionales .

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

Answer 3

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

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

Cada documento tiene varias 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 vista es una consulta de tabla cruzada que selecciona en un UNION ALL masivo de cada documento.

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

Answer 4

Las bases de datos orientadas a documentos no rechazan el concepto de relaciones, simplemente a veces permiten 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 no tienen esquema. En los almacenamientos basados ??en tablas, esta propiedad se puede lograr con una sobrecarga significativa (ver respuesta de richardtallent), pero aquí se hace de manera más eficiente. Lo que realmente deberíamos aprender al cambiar de un RDBMS a un DODB es olvidarnos de las tablas y comenzar a pensar en los datos. Eso es lo que sheepsimulator llama el "abajo hacia arriba" enfoque. Es un esquema en constante evolución, no un lecho Procrustean predefinido. Por supuesto, esto no significa que los esquemas deban abandonarse por completo de ninguna forma. Su aplicación debe interpretar los datos, restringir de alguna manera 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.

Answer 5

puede ser que deberías leer esto http://books.couchdb.org/relax/getting-started

Yo mismo lo escuché y es interesante pero no tengo idea de cómo implementar eso en la aplicación del mundo real;)

Answer 6

Una cosa que puedes probar es obtener una copia de firefox y firebug, y jugar con las funciones map y reduce en javascript. son realmente geniales y divertidos, y parecen ser la base de cómo hacer las cosas en CouchDB

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