interseccionalidad interseccional feminismo ruby database-design couchdb document-oriented-db couchpotato

ruby - interseccionalidad - feminismo interseccional pdf



Cómo dejar de pensar "relacionalmente" (6)

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.

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 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.

Las bases de datos tipo "nube" que utilizan algo como 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 cuando mira una base de datos que usa 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 que encontré que compara y contrasta bastante bien las dos bases de datos es MapReduce: A Major Step Back , que argumenta que las bases de datos de paradigmas MapReduce son un paso atrás tecnológico, y son inferiores a los RDBMS. 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.

En el trabajo, recientemente comenzamos un proyecto usando 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 vencieron 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 conectarnos a la base de datos.

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

En CouchDB, como Lotus Notes, 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 tabulación cruzada que selecciona a lo largo de una UNIÓN masiva de todos los documentos.

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.

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.

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.

Los datos no relacionales / documentales tienen sentido cuando se los desnormaliza. No cambia mucho o no te importa tanto la consistencia.

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

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

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.

Una cosa que puedes intentar es obtener una copia de Firefox y Firebug, y jugar con el mapa y reducir las funciones en JavaScript. en realidad son 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